GitLab

(This is reland of crrev.com/c/2322166. It was reverted because of a
race access of |[receive|send]_stream_| in [Receive|Send]More()
immediately after the stream was reset during
[Input|Output]Stream::Close(). This is addressed by posting stream
watcher teardown to the dedicated IO sequence. The original CL is in
Patchset 1, and the fix is in Patchset 2.)

Implement a concrete location::nearby::api::BluetoothSocket, created via
a bluetooth::mojom::Socket and Mojo DataPipes supplied by the newly
implemented BluetoothClassicMedium::ConnectToService().

Nearby Connections uses this BluetoothSocket to communicate with a
remote device. At a high-level, it first exchanges frames to encrypt
the connection, then delegates to its caller (e.g., Nearby Share)
to authenticate the connection, and finally expects its caller to
send and receive application-level messages. The following precautions
are taken to handle untrusted bytes received from remote devices:
  * Nearby Connections (including the code being added in this CL) is
    hosted in a Nearby utility process.
  * Whenever Nearby Connections provides bytes received from a remote
    device to its caller, even after it has been authenticated, the
    caller must not trust those bytes, and is responsible for first
    passing those bytes through the trusted NearbyDecoder interface
    (see go/nearby-chrome-mojo). NearbyDecoder is hosted in the same
    Nearby utility process.

api::BluetoothSocket is a synchronous interface, so this
implementation consumes the synchronous signatures of
bluetooth::mojom::Socket methods.

api::BluetoothSocket's subclasses are also synchronous interfaces,
but the Mojo DataPipes they consume only provide asynchronous
interfaces. This is reconciled by blocking on the caller thread when
waiting (via a mojo::SimpleWatcher) for the DataPipes to become
readable or writable (this is expected by the callers of
api::BluetoothSocket's subclasses). Mojo DataPipe operations are
handled on a separate task runner so that blocking on the calling
thread will not deadlock.

Please see design doc go/nearby-chrome-bt for more details.

Bug: b:154849033, b:158848873
Change-Id: Ie00b18b6675c00e32c47a979f23b5d434941ba6f
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2356271
Commit-Queue: Ryan Hansberry <hansberry@chromium.org>
Reviewed-by: James Vecore <vecore@google.com>
Reviewed-by: Reilly Grant <reillyg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#799337}