This brings back the ability for the carousel to scroll in a classic
way. It turns out this is generally what we want for "seek" operations
like "random", else it's quite hard to get the expected animation.
I did experiment with applying the animation after the pooled panels are
retrieved, but in a best-case scenario there is still a gap where no
panels are displayed during the random seek operation.
In the case of automatic scroll requirements (ie. scroll to selected) we
are delegating the animation logic to the panels themselves. In order to
make this work correctly, the scroll operation needs to take effect
before any animation updates are run.
This was causing multiple issues with masking and sizing and really
didn't need to exist in the first place. Also not sure why the pool was
nested inside the scroll container, but it isn't any more. Probably for
the best.
I think this is a pretty good place to be for now. The flair will play
if you just watched a play (local, replay or spectator) but will not
play if you are coming from song select (viewing a replay's result
screen from the leaderboard) or in the case of autoplay.
Closes#10762.
The way spectator currently works, the `Spectator` screen is responsible
for adding new frames to the replay, even when it has a child
(`SpectatorPlayer`) present.
There was a possibility that a new play had already started, and on
returning to the Spectator screen (to initialise the new play) there
would be a brief period where the Player instance is still reading from
the replay, the `userBeganPlaying` call had not yet finished
initialising the new target replay, and `userSentFrames` is run
(asynchronously), writing frames to the previous replay using the
incorrect ruleset instance).
To make this work, it doesn't `Schedule` frame addition to the replay
(making things a bit unsafe). Changing this itself isn't such a simple
one to do, so I instead opted to fix this via locking.
Closes https://github.com/ppy/osu/issues/10777.
