These are tested framework-side to throw exceptions, but the
test is ignored for the source generated version because it quietly
allows this scenario.
The source gen project should eventually have an analyser for these
unsupported cases, or we could consider relaxing this particular case.
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.