In theory this seemed like a good idea (and an optimisation in some
cases, due to lower fill rate), but in practice this leads to weird edge
cases.
This aims to do away with the operations on external drawables by
applying a dim to the area behind the `LoadingLayer` when required.
I went over each usage and ensured they look as good or better than
previously.
The specific bad usage here was the restoration of the colour on dispose
(if the `LoadingLayer` was disposed in a still-visible state).
I'm aware that the `BeatmapListingOverlay` will now dim completely during
load. I think this is fine for the time being.
Silencing an exception from a task continuation requires accessing
`task.Exception` in any way, which was not done previously if
`logOnError` was false.
To resolve without having to worry whether the compiler will optimise
away a useless access or now, just always log, but switch the logging
level. The unimportant errors will be logged as debug and therefore
essentially silenced on release builds (but could still be potentially
useful in debugging).
For better guarantees that `finalAction` is actually called on the same
screen that `checkCanComplete()` was (uses result of one
`getCurrentScreen()` call throughout instead of calling multiple times).
These can occur when a network connection is completely unavailable (ie.
host resolution failures are occurring). Currently these would appear as
important errors which spammed the notification overlay every retry
forever, while no network connection is available.
I also took this opportunity to remove a lot of `bool` passing which was
no longer in use (previously the fail count / retry process was
different to what we have today).
Looks like this was just copy-paste without any thought into whether it
should exist. It really shouldn't exist.
This is a thing for the playlists system because the *whole system*
there relies on polling the web API to get updated information. In the
case of mutliplayer, we hand off all communications to the realtime
server at the point of joining the rooms.
The argument that this was there to do faster polling on the selection
isn't valid since the polling times were the same for both cases.
Closes#11348.
It needs to be explicitly stated that the users in this list are related
to the *joined* room. Especially since it's sharing its variable name
with `SpectatorStreamingClient` where it has the opposite meaning (is a
list of *globally* playing players).
