When the model changes quickly from one discovery mode to the next, the
public device discovery agent and the internal device discovery agent
inside QBlutoothServiceDiscoveryAgent interact with each other. One agent
is shutting down while the other is starting. Since both instances
manage the same hardware, the resulting signals hit the agents in
unexpected states which even leads to random crashes.

The fix is to let one agent stop and only start the next one once the
first has properly shut down. Unfortunately the public BluetoothModel
API acts synchronously via its running property. Therefore the
synchronous running property must be mapped to asynchronous state changes
inside the agents. To achieve this the model uses an internal state
transition table which determines how the next setRunning(bool) call
is to be processed.

As a consequence it is possible to have a non-running BluetoothModel
but the internal agent is still shutting down. Another scenario
might exhibit a running model whereas one internal agent is still
finishing up and the next is waiting to start.

Task-number: QTBUG-51307
Change-Id: I0a471b913b8784d2218a797442cee7ee4d00edf3
Reviewed-by: Christian Kandeler <christian.kandeler@theqtcompany.com>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@theqtcompany.com>
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>