As far as I can tell all accesses are safe due to update thread
guarantees. The only weird one may be async writes during a
`BlockAllOperations`, but the `Compact` loop should handle this quite
amicably.
After a `BlockAllOperations`, the restoration of the `updateRealm`
instance is not instance. It is posted to a `SynchronizationContext`.
The assertion which has been removed in this commit was assuming it
would always be an immediate operation.
To ensure this works as expected, I've tracked the initialised state via
a new `bool`.
```csharp
System.TimeoutException : Attempting to block for migration took too long.
1) Host threw exception System.AggregateException: One or more errors occurred. (: )
---> NUnit.Framework.AssertionException: :
at osu.Framework.Logging.ThrowingTraceListener.Fail(String message1, String message2)
at System.Diagnostics.TraceInternal.Fail(String message, String detailMessage)
at System.Diagnostics.TraceInternal.TraceProvider.Fail(String message, String detailMessage)
at System.Diagnostics.Debug.Fail(String message, String detailMessage)
at osu.Game.Database.RealmAccess.BlockAllOperations() in /opt/buildagent/work/ecd860037212ac52/osu.Game/Database/RealmAccess.cs:line 813
at osu.Game.OsuGameBase.<>c__DisplayClass108_1.<Migrate>b__0() in /opt/buildagent/work/ecd860037212ac52/osu.Game/OsuGameBase.cs:line 449
at osu.Framework.Threading.ScheduledDelegate.RunTaskInternal()
at osu.Framework.Threading.Scheduler.Update()
at osu.Framework.Graphics.Drawable.UpdateSubTree()
at osu.Framework.Graphics.Containers.CompositeDrawable.UpdateSubTree()
```
https://teamcity.ppy.sh/buildConfiguration/Osu_Build/322?hideProblemsFromDependencies=false&hideTestsFromDependencies=false&expandBuildTestsSection=true
Contains minor changes to async usage in line with upstream API changes.
I believe a feedback issue we were seeing with offset changes (the only
component using async write flow) may have been resolved by these
upstream changes (see [release
notes](https://github.com/realm/realm-dotnet/releases/tag/10.14.0)) but
am not investigating further just yet.
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.
