* On API 29+ we need the location permission to start the hotspot, while
on lower API levels, we don't. In order to handle permissions and
other conditions in a clear manner depending the API level of the
device the app is running on, have separate extensions of the base
ConditionManager class.
* Take special care to handle situations gracefully where the Wifi is
disabled and the user tries to start the hotspot. We cannot simply
rely on Wifi being enabled as a sufficient condition that allows us to
start the hotspot. We need to wait for WifiP2p to be available. While
it is tricky to obtain that state (it involves registering a broadcast
receiver for the WIFI_P2P_STATE_CHANGED_ACTION broadcast, keeping
track of changes there and even then things are still ugly. It can
happen that WifiP2p is available *before* Wifi is. Also it can happen
that WifiP2p never becomes available because some other application
has already opened a hotspot. Instead of checking that state, we now
just try (and retry repeatedly after a delay) to start the hotspot
(and the WifiP2p framework) hoping that is becomes availabe within a
reasonable amount of time after Wifi has been detected to be on.
Currently we try 5 times with a delay of 1 second.
* Improve the behavior of disabling and re-enabling the 'start hotspot'
button, so that it becomes impossible to double-tap it, but still
making sure that the button get re-enabled as soon as the UI is back
in a state where the user should be able to tap the button again.
If HotspotActivity gets destroyed, so will be its viewmodel, resulting
in an undefined state when the activity gets created again. While the
fragments will be restored, the view model and hotspot/webserver state
will not. Fix this by resetting the UI to reflect the reset of hotspot
and webserver.
