Not entirely sure why they were failing previously, but the most likely
explanation is that by freak accident some mock requests would
previously execute immediately rather than be scheduled on the API
thread, which would change execution ordering and ensure that
`ChannelManager.CurrentChannel` would become the joined channel, rather
than remaining at the channel listing.
These used to work because there was a huge blocking load operation,
which is now more asynchronous.
Note that the change made in `SongSelect` is not required, but defensive
(feels it should have been doing this the whole time).
The only exception to the rule here was "when screen isn't active apply
without debounce" but I'm not sure we want this. It would cause a
stutter on returning to song select and I'm not even sure this is a
common scenario.
I'd rather remove it and see if someone finds an actual case where this
is an issue.
This reverts a portion of https://github.com/ppy/osu/pull/9539.
The rearrangement in `SongSelect` is required to get the initial filter
into `BeatmapCarousel` (and avoid the `FilterChanged` event firing,
causing a delayed/scheduled filter application).
I've been meaning to make the progress bar synchronise with the beat
rather than a continuous countdown, just to give the overlay a bit more
of a rhythmic feel.
Not completely happy with how this feels but I think it's a start?
I had to refactor how the break overlay works in the process. It no
longer creates transforms for all breaks ahead-of-time, which could be
argued as a better way of doing things. It's more dynamically able to
handle breaks now (maybe useful for the future, who knows).