Would lead to exceptions due to modification of `Beatmap.HitObjects`
during its enumeration by `DrawableRuleset`, which was happening as an
async load via `EditorScreenWithTimeline.CreateMainContent()`.
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.
The reason this was happening was an unfortunate oversight in the
migration logic. The code that was attempting to parse the skin settings
as `int` was firing regardless of whether a skin migration from EF to
realm had already occurred. If it had occurred, the skin setting would
contain a GUID rather than an integer, and therefore fail to parse, and
therefore implicitly fallback to a EF skin ID of 0 which would be the
default skin.
Fix by not running the setting migrating logic at all when there are no
EF skins to migrate.