If a user leave and then rejoins a multiplayer match while another user
is not at the lobby screen, there is a potential the `ParticipantPanel`
tracking the user will not correctly be recreated to reference the new
instance of the `MultiplayerUser`.
This happens because the `OnRoomUpdated` call is scheduled, which means
it is not running in the background, coupled with the local logic that
relies on `IEquatable(MultiplayerRoomUser)` (which in turn falls back to
a UserID comparison).
Changing this to a reference comparison is the easiest way to resolve
this. Whether we change the `IEquatable` implementation is up for
discussion.
Closes https://github.com/ppy/osu/issues/15970.
This covers the scenario where a user may be at the song select screen
while another user (the room host) starts the match. This was only made
possible with the new queue modes, so is quite a recent regression.
This avoids accidental usage which could result in data being lost or
ignored (as only the last `user` in a single frame would arrive).
This was added specifically to debounce sample playback, but given that
it's only debouncing on a single frame (hardly noticeable) I'm not going
to add back support for that yet. It should be handled by sample
playback concurrency or something more local to the usage.
Fixes timeout in `TestJoinRoomWithoutPassword`, because the 'server' returns
out-of-date data while the `MatchSubScreen` has possible not been entered
yet (and thus hasn't disabled polling itself yet).
Can be tested by adding a `Task.Delay(3000);` at the end of
the `MultiplayerClient.JoinRoom()` task.
These can be tested by adding a `Task.Delay(3000);` at the end of the
`MultiplayerClient.JoinRoom` task. The reason is typically that
`Client.Room` becomes not-null but the join task still hasn't completed
yet, so e.g. the ready button is still disabled.
