bluetooth: Implement known_service_uuids for Peripherals.

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 536842e502487e29ec6d09eec3117272e81b94ce..a9d71faed3b86028292d428c6ecfc4b466a837ec 100644
--- a/device/bluetooth/public/interfaces/test/fake_bluetooth.mojom
+++ b/device/bluetooth/public/interfaces/test/fake_bluetooth.mojom
@@ -4,6 +4,8 @@
 
 module bluetooth.mojom;
 
+import "device/bluetooth/public/interfaces/uuid.mojom";
+
 // FakeBluetooth and its related interfaces allow clients to control the global
 // Bluetooth State as well as simulate Bluetooth events including finding new
 // devices, simulating GATT attributes and its descendants, and simulating
@@ -38,13 +40,15 @@ 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.
+  // Simulates a peripheral with |address|, |name| and |known_service_uuids|
+  // that has already been connected to the system. If the peripheral existed
+  // already it updates its name and known UUIDs.
   //
   // 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) => ();
+  SimulatePreconnectedPeripheral(string address,
+                                 string name,
+                                 array<UUID> known_service_uuids) => ();

[dcheng, 2017/05/11 05:44:21]

Not a blocker for this CL, but my previous comment about not just wrapping a
string as the mojo type and then enforcing structure on it applies here. That
being said, I'm not sure how annoying it would be to convert from a GUID string
(in BluetoothUUID) to a 128bit binary representation back to a GUID string: I
get the sense that probably it's not /too/ bad.

[ortuno, 2017/05/11 06:45:08]

I'm unsure what the benefits of sending binary data over a string are here. All
parts of the Bluetooth stack, from Web APIs down to the platform APIs use the
string representation of the UUIDs. It seems a bit unnecessary to convert them
to binary data just to send them over.

 };