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.
