Mostly trying to give more space to the queue as we add more vertical
elements to the middle area of multiplayer / playerlists. This whole UI
will likely change – this is just a stop-gap fix.
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.