Avoid invalid state in search/discovery queue state machine

The sequence of events in the state machine that causes the bug is as follows:
- We start a search, and move from the IDLE state to the SEARCH_ACTIVE state.
- We initiate a pairing request, that sets pairing_cb.state to BT_BOND_STATE_BONDING.
- We cancel the search, returning to the IDLE state.
- We then try to start a second search. In BTA_DmSearch, we check if we are bonding, and if so enqueue the request.
- But we remain in the IDLE state! So we never dequeue the search request, getting us into the stuck state.

This CL fixes the issue by removing the *_QUEUE_* events, making the state machine the single arbiter for whether a request should be executed or queued. In particular, for the above scenario, the SDP request will queue behind the second search request, if it arrives afterwards, *even if* bonding has already begun. This prevents us from getting in a stuck state.

I believe that this is safe since we preserve the invariant of only ever have one request going through at a time, but manual testing is needed to be certain. The preservation of this invariant also means that we should not regress b/237352700, though I am unable to test that.

Bug: 230277335
Test: Manual, using the repro steps from the bug thread.
Tag: #stability

Change-Id: I74e83964995b10f4bee35bae3182ec482bdedb39
(cherry picked from commit d197ce9a)
Merged-In: I74e83964995b10f4bee35bae3182ec482bdedb39