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).
`TestSceneRealtimeReadyButton` was manually adding `API.LocalUser`,
which wasn't actually needed. The base `RealtimeMultiplayerTestScene` by
default creates a new room as `API.LocalUser`, therefore automatically
adding that user to the room - and as such there is no need to add them
manually unless the `joinRoom` ctor param is specified as `false`.
Note the reversal of the order of operations in `endHandlingTrack()`
(done for extra safety, to ensure no more value changed events can be
fired at the point of cancelling looping).