If there are pending pan requests for an enable but a disable request
comes (or vice versa), remove all the pending requests and pre-emptively
fail their result listeners. This simplifies the logic and helps us
keep track of which request the future link layer event should be long
to.
Technically this is an app-visible behaviour change. In particular, if
something disables bluetooth tethering while the service is
disconnected and request(s) to enable tethering are queued, then the new
code will immediately send onTetheringFailed to all those requests,
whereas the old code would wait until the service connects, enable
tethering (and send the enabler an onTetheringStarted), and then disable
it. Given that this situation is very rare, and Bluetooth tethering is
itself so uncommon (<1% of total tethering sessions) this is an
acceptable trade-off.
Bug: 216524590
Test: atest TetheringTest
Change-Id: I061733d714894b741e7d686810dd39f054e85476
9cebb8c3b1