While usually we'd handle this locally by moving bind operations to
`LoadComponent`, this component was explicitly made to be used in
asynchronous scenarios (to allow cases like song select to coexist with
realm without adding huge compliexities to the classes locally).
So I think it makes sense to hide this as an implementation detail. The
locked segments should all be quite fast to run so I do not see a
performance issue with lock contention here.
Yesterday after the lazer release there was a bit of a spike in the
number of osu-web requests pointed at `/api/v2/beatmaps/lookup`
specifically. The most likely reason for this is that prior to this
commit, the star rating recalculation was fully performed by the
`BeatmapUpdater.Process()` flow.
This process does full metadata lookups, and while it *will* attempt
to use the local `online.db` metadata cache, it *will* also fall back to
API requests if the local metadata fetch fails. While that means that
the local cache likely saved us from a doomsday scenario here, it *also*
is the case that all of that metadata lookup stuff is *entirely
unnecessary* when wanting to just update star ratings.
Therefore, this splits out only the part relevant to star ratings
as a separate background process, so that it can run completely
locally.
Done for two reasons:
- During review it was requested for the logic to be moved out of
`BezierConverter` as `BezierConverter` was intended to produce
"lazer style" sliders with per-control-point curve types,
as a future usability / code layering concern.
- It is also relevant for encode-decode stability. With how the logic
was structured between the Bezier converter and the legacy beatmap
encoder, the encoder would leave behind per-control-point Bezier curve
specs that stable ignored, but subsequent encodes and decodes in lazer
would end up multiplying the doubled-up control points ad nauseam.
Instead, it is sufficient to only specify the curve type for the
head control point as Bezier, not specify any further curve types
later on, and instead just keep the double-up-control-point for new
implicit segment logic which is enough to make stable cooperate
(and also as close to outputting the slider exactly as stable would
have produced it as we've ever been)
The intention here is to make things more testable going forward.
Specifically, to remove the "back-door" entrance into `BeatmapCarousel`
where `BeatmapSets` can be set by tests and bypas/block realm retrieval.
This fell out while investigating why the issue with online IDs
mismatching in the `.osu` could be worked around by importing the map
three times in total when starting from it not being available locally.
Here follows an explanation of why that "helped".
Import 1:
- The beatmap set is imported normally.
- Online metadata population sees the online ID mismatch and resets it
on the problematic beatmap.
Import 2:
- The existing beatmap set is found, but deemed not reusable
because of the single beatmap having its ID reset to -1.
- The existing beatmap set is marked deleted, and all the IDs of
its beatmaps are reset to -1.
- The beatmap set is reimported afresh.
- Online metadata population still sees the online ID mismatch
and resets it on the problematic beatmap.
Note that at this point the first import *is still physically present
in the database* but marked deleted.
Import 3:
- When trying to find the existing beatmap set to see if it can be
reused, *the one pending deletion and with its IDs reset -
- the remnant from import 1 - is returned*.
- Because of this, `validateOnlineIds()` resets online IDs
*on the model representing the current reimport*.
- The beatmap set is reimported yet again.
- With the online ID reset, the online metadata population check for
online ID mismatch does not run because *the IDs were reset to -1*
earlier.
Preferring undeleted models when picking the model instance for reuse
prevents this scenario.