GitLab

Always request bluez to stop discovery; do not gate on whether or not
discovery is active.

The recent refactor crrev.com/c/1699214 in BluetoothAdapter and its
children classes resurfaced a buggy implementation of
BluetoothAdapterBluez::IsDiscovering() (crbug.com/905374) -- its
implementation in bluez can sometimes return an incorrect value. In this
particular bug, crbug.com/1013020, when ARC++ spammed BluetoothAdapterBluez
with too many Start/Stop scan calls, we entered a racy situation in which
ARC++ called StopScan(), and that StopScan() incorrectly early-returned,
failing to stop discovery, because BluetoothAdapterBluez::IsDiscovering()
incorrectly returned 'false'.

      the repro steps described in crbug.com/1013020.

Bug: 1013020, 822104, 905374
TEST: Manaully verified 5 times on both M78 branch and ToT following
Change-Id: Ide80706d77f1659cc07f457c4a524d823141f2c2
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1854459
Commit-Queue: Ryan Hansberry <hansberry@chromium.org>
Reviewed-by: Reilly Grant <reillyg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#704863}