The code here was assuming that if the beatmap which is having changes
copied across does not exist within the `BeatmapSet.Beatmaps` list, it
was not yet persisted to realm.
In some edge case, it can happen that the beatmap *is* persisted to
realm but not correctly attached to the beatmap set. I don't yet know
how this occurs, but it has caused loss of data for at least two users.
The fix here is to check realm-wide for the beatmap (using its primary
key) rather than only in the list. We then handle the scenario where the
beatmap needs to be reattached to the set as a seprate step.
---
This does raise others questions like "are we even structuring this
correctly? couldn't a single beatmap exist in two different sets?"
Maybe, but let's deal with that if/when it comes up.
Previously, if the backup procedure failed, startup would continue and
the user's realm database may be deleted. I think in such a fail case
I'd rather the game didn't startup so the user gets in touch (or reads
the log files themselves) rather than potentially losing data.
The whole restructure here is to move the nested call out of the
`try-catch`. I noticed this while looking at a corrupt database issue a
user reported (https://github.com/ppy/osu/discussions/23694).
It's not the first time we've seen a corrupt database error where the
"corrupt" version works just fine on a second attempt.
Maybe this isn't the issue and it's just a transitive file access violation
but it definitely feels like this should be fixed regardless.