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).
The fix here is correcting the access of `user.Country`. The deicision
to have null users display is because this is the best we can do (if
osu-web could not resolve the user). We still want the users in the
lobby to be aware of this user's presence, rather than hiding them from
view.
osu-stable does a similar thing, showing these users as `[Loading]`. I
decided to go with blank names instead because having *any* text there
causes confusion. We can iterate on this in future design updates.
Fixes test failures due to not allowing to do so, therefore inverting
execution order in some cases - for example, calling
JoinRoom(room);
LeaveRoom();
on the update thread would invert execution order due to the first being
unscheduled but the second being scheduled.
`getRoomUsers()` was not safe to call from the update thread, as
evidenced by the test failures. This was due to the fact that the added
reset event could never actually be set from within the method, as the
wait was blocking the scheduled set from ever proceeding.
Resolve by allowing the scheduled copy & set to run inline if on the
update thread already.
