This allows each implementation to have control over scheduling. Without
this, the solo implementation would not be able to handle quit events
while watching a player, as it would push a child (gameplay) screen to
the stack where the `SpectatorScreen` would usually be.
When watching from the middle of gameplay, due to a series of failures,
`SpectatorClock` would not get seeked to the current time, causing all
clients to look like they were out of sync.
This is a hotfix for the issue. A better fix will require framework
changes or considerable restructuring.
I'd recommend testing this works in practice and agreeing that while it
is a hack, it's likely not going to cause issues and is something we
want to see fixed sooner rather than later.
In some scenarios, multiplayer spectator would not tick over to the next
beatmap.
Here's an example:
- Room has two items queued
- Local user starts download of both
- First beatmap starts and download is complete
- First beatmap ends (spectating is active)
- Second beatmap starts but download is not complete
In this scenario, the local client will get stuck at the spectator
screen due to the `onLoadRequested`-invoked screen change being early
exited.
It would require manual recovery (clicking back button) to return to a
sane state.
If `IAPIProvider.State` changes from `Online` at any point when being on
an `OnlinePlayScreen`, it will be forcefully exited from. However,
`MultiplayerMatchSubScreen` had local logic that suppressed the exit in
order to show a confirmation dialog.
The problem is, that in the suppression logic,
`MultiplayerMatchSubScreen` was checking
`MultiplayerClient.IsConnected`, which is a SignalR flag, and was not
checking `IAPIAccess.State`, which is maintained separately. Due to
differing timeouts and failure thresholds, it is not impossible to have
`MultiplayerClient.IsConnected == true` but `IAPIAccess.State !=
APIState.Online`.
In such a case, the match subscreen would wrongly consider itself to be
still online and due to that, push useless confirmation dialogs, while
being in the process of being forcefully exited. This then caused the
dialog to cause a crash, as it was calling `.Exit()` on the screen which
would already have been exited by that point, by the force-exit flow.
