device/bluetooth: Remove BluetoothAdapter::Start|StopDiscovering.

device/bluetooth: Remove BluetoothAdapter::Start|StopDiscovering.

This CL removes all remaining references to the deprecated
device::BluetoothAdapter::StartDiscovering and
device::BluetoothAdapter::StopDiscovering methods. This CL also does
a minor refactor, so that BluetoothAdapter now only tracks active
discovery sessions.

BUG=346985
TEST=Compile chrome; run device_unittests.

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=255809

[keybuk, 2014-03-06 18:42:35]

https://codereview.chromium.org/188473002/diff/20001/device/bluetooth/bluetoo...
File device/bluetooth/bluetooth_adapter.cc (right):

https://codereview.chromium.org/188473002/diff/20001/device/bluetooth/bluetoo...
device/bluetooth/bluetooth_adapter.cc:119: discovery_sessions_.clear();
This seems to contradict the comment in the header that says that the
DiscoverySession will remove itself from the list when destroyed

[armansito, 2014-03-06 23:55:48]

https://codereview.chromium.org/188473002/diff/20001/device/bluetooth/bluetoo...
File device/bluetooth/bluetooth_adapter.cc (right):

https://codereview.chromium.org/188473002/diff/20001/device/bluetooth/bluetoo...
device/bluetooth/bluetooth_adapter.cc:119: discovery_sessions_.clear();
On 2014/03/06 18:42:36, keybuk wrote:
> This seems to contradict the comment in the header that says that the
> DiscoverySession will remove itself from the list when destroyed

Well, it doesn't really contradict it, as discovery sessions still remove
themselves. Here I clear the list as an optimization as they are really no
longer needed to be kept in the adapter's list. The comment in the header is
mostly to justify keeping raw pointers as opposed to weak pointers. I can update
the comment though, if you think that should be clarified further.

[keybuk, 2014-03-06 23:57:39]

https://codereview.chromium.org/188473002/diff/20001/device/bluetooth/bluetoo...
File device/bluetooth/bluetooth_adapter.cc (right):

https://codereview.chromium.org/188473002/diff/20001/device/bluetooth/bluetoo...
device/bluetooth/bluetooth_adapter.cc:119: discovery_sessions_.clear();
because we're dealing with object lifetime, I think it should be clear

e.g. note that the list only contains ACTIVE discovery sessions, that they're
removed from the list when made inactive, and also removed when deleted

[armansito, 2014-03-07 19:22:16]

https://codereview.chromium.org/188473002/diff/20001/device/bluetooth/bluetoo...
File device/bluetooth/bluetooth_adapter.cc (right):

https://codereview.chromium.org/188473002/diff/20001/device/bluetooth/bluetoo...
device/bluetooth/bluetooth_adapter.cc:119: discovery_sessions_.clear();
On 2014/03/06 23:57:39, keybuk wrote:
> because we're dealing with object lifetime, I think it should be clear
> 
> e.g. note that the list only contains ACTIVE discovery sessions, that they're
> removed from the list when made inactive, and also removed when deleted

Actually they weren't removed when an individual one became active, but when all
of them collective got marked as inactive. I decided to change the logic so that
only pointers to active sessions are kept in |discovery_sessions_| and updated
the comments to reflect this.

[keybuk, 2014-03-07 19:34:36]

https://codereview.chromium.org/188473002/diff/40001/device/bluetooth/bluetoo...
File device/bluetooth/bluetooth_adapter.cc (right):

https://codereview.chromium.org/188473002/diff/40001/device/bluetooth/bluetoo...
device/bluetooth/bluetooth_adapter.cc:118: discovery_sessions_.clear();
if the discovery session is marking itself as inactive, why the call to .clear()
?

[armansito, 2014-03-07 19:56:52]

https://codereview.chromium.org/188473002/diff/40001/device/bluetooth/bluetoo...
File device/bluetooth/bluetooth_adapter.cc (right):

https://codereview.chromium.org/188473002/diff/40001/device/bluetooth/bluetoo...
device/bluetooth/bluetooth_adapter.cc:118: discovery_sessions_.clear();
On 2014/03/07 19:34:36, keybuk wrote:
> if the discovery session is marking itself as inactive, why the call to
.clear()
> ?

I guess it's a bit redundant, and a call to erase happens in
DiscoverySessionBecameInactive anyway which will do an unnecessary look up, so
removing it.

[keybuk, 2014-03-07 20:01:59]

lgtm

[armansito, 2014-03-08 04:03:49]

The CQ bit was checked by armansito@chromium.org

[armansito, 2014-03-08 06:49:12]

The CQ bit was unchecked by armansito@chromium.org

[armansito, 2014-03-09 00:17:03]

The CQ bit was checked by armansito@chromium.org

[commit-bot: I haz the power, 2014-03-09 00:17:08]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/armansito@chromium.org/188473002/120001

[commit-bot: I haz the power, 2014-03-09 01:18:11]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2014-03-09 01:18:11]

Retried try job too often on mac_rel for step(s) telemetry_perf_unittests
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=mac_rel&nu...

[armansito, 2014-03-09 02:16:19]

The CQ bit was checked by armansito@chromium.org

[commit-bot: I haz the power, 2014-03-09 02:16:36]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/armansito@chromium.org/188473002/120001

[commit-bot: I haz the power, 2014-03-09 02:43:26]

Change committed as 255809