* Fix play button starting wrong beatmap before selection loads
When clicking the osu! cookie (play button) before a newly selected beatmap finishes loading, the previous beatmap would be played instead of the currently selected one.
This was caused by the cookie reading from the global beatmap state which is debounced by 150ms, while the Enter key correctly used the carousel's current selection.
The fix makes the cookie use the same beatmap source as Enter - the carousel's current selection - which is always up-to-date regardless of debounce timing.
Closes#36074
* Use ensureGlobalBeatmapValid() for logo and Enter key actions
* Add test for beatmap selection timing bug
Tests the fix for issue #36074 where clicking the play button immediately after selecting a different difficulty would start the wrong beatmap due to the 150ms selection debounce.
Additionally to fix the options button, I could either cache the
interface in PlaylistsSongSelectV2 or make the interface cache itself. I
went with the latter option.
The test scene doesn't exercise the custom sample playback, but I hope I
can be forgiven for this as setting up a custom editor beatmap just for
this to work is rather cumbersome.
First part of https://github.com/ppy/osu/issues/36039, see also
https://github.com/ppy/osu/discussions/33784.
The goal is to add this back to the set panels too, but that one is more
complicated than this if you can believe it (because it requires being
able to tell which other difficulties of the set are filtered out to
fade them out). I also foresee the display logic to vary significantly
there.
Of note, for this to work in beatmaps-split-apart mode, this requires a
change of behaviour in the filtering logic. Old song select when given a
"selected beatmap set" would *include* that in results regardless of the
filter, but that doesn't work for beatmaps-split-apart for reasons that
are hopefully obvious, so this changes the behaviour to *entirely
bypass* the filter and just show the set. Unsure how angry will people
be with that.
Also of note, when in the scoped mode, altering any filter criteria will
dismiss the scope.
* Add failing test for copy->paste not being idempotent
* Ensure all elements on default skins use fixed anchors
`UsesFixedAnchor` defaults to false, i.e. closest anchors. Combined with
manual anchor / origin specs on some drawables, this would get default
skins into impossible states wherein a drawable would use "closest
anchor" but also explicitly specify anchor / origin that aren't closest,
which horribly fails on attempting to copy and paste.
Frankly shocked this has gone unnoticed for this long, and I regret not
vetoing this "feature" more every time I see its tentacles spread to
produce breakage of levels yet unseen.
Does this commit contain major levels of suck? For sure. Do I have any
better ideas that wouldn't consist of a multi-day rewrite or deletion of
this "feature"? No.
* Fix skin editor always applying closest anchor / origin on paste regardless of whether the component uses fixed anchor
Self-explanatory. Should close https://github.com/ppy/osu/issues/29111
along with previous commit.