There was a lot of weirdness here, such as storing the playing users,
clearing the playing users from test scenes (!!), and storing the users
being wathed.
This was all a thing because the previous implementation overrode the
base method implementations, which is no longer a thing.
The editor clock, which is responsible for performing the seek, was not
aware of changes in control points due to reading from the wrong
beatmap. `loadableBeatmap` is not actually changed by any of the editor
components; `playableBeatmap` and `editorBeatmap` are.
For now this is changed to use `playableBeatmap`. A better follow-up
would be to use `editorBeatmap`, but it would probably be best to move
the beat snap bindable into `EditorBeatmap` first.
Finishing an operation started via
`OngoingOperationTracker.BeginOperation()` was risky in cases where the
operation ended at a callback on another thread (which, in the case of
multiplayer, is *most* cases). In particular, if any consumer registered
a callback that mutates transforms when the operation ends, it would
result in crashes after the framework-side safety checks.
Rework `OngoingOperationTracker` into an always-present component
residing in the drawable hierarchy, and ensure that the
`operationInProgress` bindable is always updated on the update thread.
This way consumers don't have to add local schedules in multiple places.
The fix here is correcting the access of `user.Country`. The deicision
to have null users display is because this is the best we can do (if
osu-web could not resolve the user). We still want the users in the
lobby to be aware of this user's presence, rather than hiding them from
view.
osu-stable does a similar thing, showing these users as `[Loading]`. I
decided to go with blank names instead because having *any* text there
causes confusion. We can iterate on this in future design updates.