Initial pass at socketpair() based CDM transport.

Based on design conversations with the team, it's more robust to
rely on a CDM companion service to provide a "streaming" interface
between two devices, instead of building our own message
fragmentation and reassembly logic.  (Most transports such as
Bluetooth RFCOMM will already be doing their own fragmentation, so
we don't need to duplicate that work.)

Additionally, this change uses socketpair() for the bidirectional
data transfer between the companion service and the system_server,
avoiding additional Binder transaction load while handling its own
chunking, at the expense of dedicating two threads to "shovel" data
in each direction.

This change attempts to implement the design in the most
straightforward way possible to reduce risk; there are several
opportunities to optimize the thread usage using tools like
MessageQueue.addOnFileDescriptorEventListener(), but those will
need to wait for a future iteration.

Also includes basic functionality tests that exercise a PING/PONG
command to verify many different edge cases; they're currently all
passing.

Bug: 237030169
Test: atest CompanionTests
Change-Id: I075128fa60379f47400345b211a07d9a32391155

0 files changed, 0 insertions, 0 deletions