bluetooth: Implement simulatePreconnectedPeripheral.

device/bluetooth/public/interfaces/test/fake_bluetooth.mojom

Index: device/bluetooth/public/interfaces/test/fake_bluetooth.mojom
diff --git a/device/bluetooth/public/interfaces/test/fake_bluetooth.mojom b/device/bluetooth/public/interfaces/test/fake_bluetooth.mojom
index 826df33b68d5588e0cff8670e12fb4960864f641..536842e502487e29ec6d09eec3117272e81b94ce 100644
--- a/device/bluetooth/public/interfaces/test/fake_bluetooth.mojom
+++ b/device/bluetooth/public/interfaces/test/fake_bluetooth.mojom
@@ -38,4 +38,13 @@ interface FakeBluetooth {
 // See Bluetooth 4.2 Vol 3 Part C 2.2.2 "Roles when Operating over an
 // LE Physical Transport".
 interface FakeCentral {
+  // Simulates a peripheral with |address| and |name| that has already
+  // been connected to the system. If the peripheral existed already it
+  // updates its name.
+  //
+  // Platforms offer methods to retrieve devices that have already been
+  // connected to the system or weren't connected through the UA e.g. a user
+  // connected a peripheral through the system's settings. This method is
+  // intended to simulate peripherals that those methods would return.
+  SimulatePreconnectedPeripheral(string address, string name) => ();

[dcheng, 2017/05/05 06:18:48]

Is there any structure to either of these fields? The ARC++ Bluetooth code
passes address as a fixed-length byte buffer IIRC. Can we/should we be doing
that here?

IIRC, using more structured identifiers was a request from palmer@ as well in
other parts of the web blutooth mojom interface.

[ortuno, 2017/05/08 01:08:13]

They are MAC Address so "00:00:00:00:00:00".
It's unclear to me why we pass the address as an array for Arc++. Most users of
the device/bluetooth need the address in form of a string e.g. extensions,
system tray, etc.

We could add a struct and validate the format but I think the benefit,
validating test addresses, might not be worth it.

[dcheng, 2017/05/09 04:20:07]

Does this show up in other parts of the mojo interface? It's more about using a
consistent type across both non-test and test interfaces, and making sure that
we're handling them uniformly.

[ortuno, 2017/05/09 04:25:12]

Besides Arc++, the only Bluetooth related Mojo interface we currently have is
web_bluetooth.mojom which does not use the address (it uses WebBluetoothDeviceId
which as you point out palmer@ requested). 

There is a chance the eventual BT Mojo interface/service would use a type for
it.

 };