Expose device RSSI and Tx power via the chrome.bluetooth API.

chrome/common/extensions/api/bluetooth_private.json

 [
   {
     "namespace": "bluetoothPrivate",
     "description": " Use the <code>chrome.bluetoothPrivate</code> API to control the Bluetooth\n adapter state and handle device pairing.",
     "compiler_options": {
       "implemented_in": "chrome/browser/extensions/api/bluetooth/bluetooth_private_api.h"
     },
     "functions": [
       {
         "description": "Changes the state of the Bluetooth adapter.",
@@ skipping 18 matching lines @@
             "$ref": "SetPairingResponseOptions"
           },
           {
             "type": "function",
             "name": "callback",
             "parameters": []
           }
         ],
         "name": "setPairingResponse",
         "type": "function"
+      },
+      {
+        "parameters": [

[not at google - send to devlin, 2014/04/23 01:34:13]

odd having parameters at the start. same for other functions.

[Ilya Sherman, 2014/04/23 01:36:00]

I thought so too, but was matching the local style of this file.  Would you
prefer me to change it as part of this CL, or in a separate CL?

+          {
+            "name": "address",
+            "type": "string",
+            "description": "The Bluetooth address of the device."
+          },
+          {
+            "type": "function",
+            "name": "callback",
+            "parameters": [
+              {
+                "name": "rssi",
+                "type": "integer",
+                "description": "The RSSI of the device."
+              }
+            ]
+          }
+        ],
+        "name": "getDeviceRSSI",

[keybuk, 2014/04/23 08:59:19]

If the RSSI is simply a property of the device, there seems to be no reason for
this to be added to the private API as a method with a callback - it could be
added to the chrome.bluetooth Device object as a property

Even if the RSSI is a callback to controller method for the adapter, it doesn't
seem out of scope to add this to the public API

[Ilya Sherman, 2014/04/24 06:45:16]

The intent is to be able to poll for the current RSSI of a connected device. 
I'm happy to add this to the public API if you think that's a more appropriate
location for it.

We were also planning to expose the transmit (Tx) power of the adapter.  Does it
seem reasonable to add that to the public API as well?

[keybuk, 2014/04/24 11:25:52]

I think both of these things can go in the public API

Especially for LE, writing proximity apps is something everyone should do


If the host subsystem is doing the polling, and maintaining the values, then
this can just be a property of bluetooth.Device

+        "type": "function",
+        "description": "Returns the RSSI of a Bluetooth device."
       }
     ],
     "events": [
       {
         "description": "Fired when a pairing event occurs.",
         "parameters": [
           {
             "description": "A pairing event.",
             "name": "pairingEvent",
             "$ref": "PairingEvent"
@@ skipping 132 matching lines @@
             "optional": true,
             "name": "passkey",
             "type": "integer",
             "description": "An integer between 0-999999 set in response to <code>requestPasskey</code>."
           }
         }
       }
     ]
   }
 ]