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).
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).
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.
While test failures fixed in 9843da5 were a shortcoming of the test,
they exposed a potential vulnerable point of the multiplayer client
logic. In case of unreliable message delivery it is not unreasonable
that duplicate messages might arrive, in which case the same scenario
that failed in the tests could crash the game.
To ensure that is not the case, explicitly screen each new joined user
against the room user list, to ensure that duplicates do not show up.
`UserLeft` is already tolerant in that respect (if a user is requested
to be removed twice by the server, the second removal just won't do
anything).
