The subscription in which the guards were present was moved from
constructor to `ApplyDefaults()`, and at that point neither the sample
control point or the difficulty point can be the default point, because
there are explicit paths that overwrite those with blank points in the
same methods, prior to the subscription's registration.
The only worry would be that someone would set the default point on the
object themselves, but at that point that is most likely programmer
error anyhow.
In editor contexts, the `StartTimeBindable` subscription in `HitObject`
was firing before defaults were applied, which in the case of sliders
manifested in an infinite end time. `ApplyDefaults()` also did not
always set the time of the control point to the correct value, which
matters when the beatmap is encoded.
Ensure that the control points receive the correct time values during
default application, and only register the `StartTimeBindable` change
callback after defaults have been successfully applied.
The tests were relying on the `RulesetID` being set to 0 in the example
beatmap, even though the ruleset *instance* was set to ID 5.
This explicitly adds that 0 value to show intent, and also removes the
incorrect specification of 5 (which would cause the convert filter tests
to fail).
Also updates the filter code to use `OnlineID`, which is required in
realm changes.
While displaying replays, the colour of the toolbox toggle button would
not match the actual state of the rest of the toolbox, i.e. both buttons
would be white, even though the "playback settings" section was expanded
and as such should have a yellow toggle button.
In the case of the replay player, the failure scenario was as follows:
1. `SettingsToolboxGroup` calls `updateExpanded()` in its BDL to update
the initial state of the toolbox, including the toggle button
colour, by adding a colour fade transform.
2. An ancestor of both the toolbox groups - `PlayerSettingsOverlay`,
which is a `VisibilityContainer` - calls `FinishTransforms(true)` in
its `LoadCompleteAsync()`, therefore instantly applying the colour
from point (1) to the toggle button instantly.
3. However, `IconButton` inherits from `OsuAnimatedButton`. And
`OsuAnimatedButton` changes its colour in `LoadComplete()`, therefore
undoing the instant application from point (2).
This conjunction of circumstances is instrumental to reproducing the
bug, because if the `FinishTransforms(true)` call wasn't there, point
(3) wouldn't matter - the transform would get applied at some
indeterminate point in the future, ignoring the write from
`OsuAnimatedButton`.
As for the fix, move the `updateExpanded()` call in
`SettingsToolboxGroup` to `LoadComplete()` to avoid the above
unfortunate order. Applying initial visual state in `LoadComplete()` is
the idiomatic style of doing things these days anyhow.
Was previously not handled at all, therefore displaying request failures
in the test log output. While that was mostly a red herring and
shouldn't have caused any actual *test* failures, it is still better to
handle this explicitly in a realistic manner.
