The main goal here is to ensure the connection is built each connection
attempt. Previously, the access token would never be updated, leading to
outdated tokens failing repeatedly (in the connection retry loop) and
never being able to establish a new connection as a result.
Due to threading considerations, this isn't as simple as I would hope it
to be. I'm open to proposals as to a better way of handling this.
Also, keep in mind that this logic will need to be abstracted and
(re)used in `SpectatorClient` as well. I've intentionally not done that
yet until we agree that this is a good direction forward.
On Android, users were unable to join or create multiplayer rooms. The
root cause of that was that the both the wait and set of the
`ManualResetEvent` in `getRoomUsers` occurred on the same thread, which
created a chicken-and-egg situation - the set could not proceed until
the wait had actually completed.
Resolve by substituting the `ManualResetEvent` for a
`TaskCompletionSource` to achieve a promise-style task, which the
previous code was a crude approximation of anyway.
Closes#11385.
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.
