As pointed out in https://github.com/ppy/osu/discussions/16435, beatmaps
with too many control points (usually added via external automation
apps) could cause the lazer editor to grind to a halt.
The overheads here are mostly from the GL side. An eventual goal would
be to render this in a smarter way, rather than using thousands of
drawables. Until that, this optimisation should help reduce the overhead
by omitting control points in close proximity that are redundant for
display purposes.
I've tried to contain this in the display logic directly, with the goal
that it can be ripped out as fast as it was added. Certainly required
more changes than I hoped for, but I don't think it's too ugly.
In general we're doing things correctly so the realm file shouldn't
expand (unless mass deletions are made from it), but this is a nice way
to manually confirm the behaviour.
Sometimes if using realm studio with osu! running, for instance, the
realm file size can blow out of proportion. This will recover from such
cases.
Note that calling `RealmFactory.Compact` itself is not enough, as it
will fail unless all instances of the realm have been closed.
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.
