There were no usages of more than one column being provided per row, so
it seemed like unnecessarily complexity. I'm currently trying to reduce
complexity so we can improve the layout of the results screen, which
currently has up to three levels of nested `GridContainer`s.
Of note, I can't add backwards compatibility because the method
signature has not changed in `Ruleset` (only the return type). If we do
want to keep compatibility with other rulesets, we could designate a new
name for the updated method.
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.
I don't feel too confident with the default scoring function being
assigned in the constructor to a publicly settable delegate. This just
feels a bit more elegant, and handles the (likely-never-used) case where
we need to restore the default function.
An alternative would be to provide the function as a `ctor` argument,
but I believe that wasn't done here to allow using the
`ILeaderboardScore` interface.
This isn't strictly required, but only because of a kind of hacky
behaviour where `HUDOverlay` will recreate all components on a scoring
mode change currently (see
8f6df5ea0f/osu.Game/Screens/Play/HUDOverlay.cs (L410-L418)).
Best we do this just in case that happens to go away in the future.
