Turns out that there are more than zero users that are upgrading from
old databases. I think we probably want to support this for now.
Tested against database in https://github.com/ppy/osu/discussions/16700
and one other I had locally, both work correctly.
Closes#16651.
When a ruleset is not available, the `Find` call would return null. When
a null is passed to the constructor, `BeatmapInfo` would create an "osu"
ruleset, which tries to get stored to realm and fails on duplicate
primary key.
Probably need to add better safeties against this (or change that
constructor...) but this will fix the migration process.
Probably not serious enough to pull the build. This only affects
rulesets like karaoke which have custom beatmaps.
There's no real way to recover these unless we want to start importing
rulesets into realm. And that seems counter productive. This can only
happen if users don't have the dll present any more, and it was removed
far before realm was tracking rulesets (else it would have an
`Available=0` entry in realm to match).
One of my pending work items for post-realm merge.
The lowest-level import task is no longer asynchronous, as we don't want
it to span multiple threads to allow easier interaction with realm.
Removing the `Task` spec simplifies a heap of usages.
Individual usages should decide whether they want to run the import
asynchronously, by either using an alternative override or spooling up a
thread themselves.
If the operation timed out on..
```csharp
throw new TimeoutException(@"Took too long to acquire lock");
```
..from an update thread, it would not restore the update context.
The next call would then fail on the assert that ensures a non-null
context in such cases.
Can add test coverage if required.