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.
Not really sure how to improve this further, but should help with cases
like this:
```csharp
[runtime] 2022-06-28 05:32:06 [verbose]: 💨 Class: TestSceneSpectatorPlayback
[runtime] 2022-06-28 05:32:06 [verbose]: 🔶 Test: TestWithSendFailure
[runtime] 2022-06-28 05:32:06 [verbose]: 🔸 Step #1 Setup containers
[runtime] 2022-06-28 05:32:06 [verbose]: Received 1 new frames (total 1 of 2)
[runtime] 2022-06-28 05:32:06 [verbose]: 🔸 Step #2 received frames
[runtime] 2022-06-28 05:32:06 [verbose]: Received 6 new frames (total 7 of 8)
[runtime] 2022-06-28 05:32:06 [verbose]: Received 6 new frames (total 13 of 19)
[runtime] 2022-06-28 05:32:06 [verbose]: Received 6 new frames (total 19 of 29)
[runtime] 2022-06-28 05:32:06 [verbose]: Received 6 new frames (total 25 of 44)
[runtime] 2022-06-28 05:32:06 [verbose]: Received 6 new frames (total 31 of 45)
[runtime] 2022-06-28 05:32:06 [verbose]: Received 6 new frames (total 37 of 59)
[runtime] 2022-06-28 05:32:06 [verbose]: Received 6 new frames (total 43 of 67)
[runtime] 2022-06-28 05:32:06 [verbose]: Received 6 new frames (total 49 of 125)
[runtime] 2022-06-28 05:32:06 [verbose]: Received 6 new frames (total 55 of 126)
[runtime] 2022-06-28 05:32:06 [verbose]: Received 6 new frames (total 61 of 127)
[runtime] 2022-06-28 05:32:06 [verbose]: Received 6 new frames (total 67 of 128)
[runtime] 2022-06-28 05:32:06 [verbose]: Received 6 new frames (total 73 of 129)
[runtime] 2022-06-28 05:32:06 [verbose]: Received 6 new frames (total 79 of 130)
[runtime] 2022-06-28 05:32:06 [verbose]: Received 6 new frames (total 85 of 131)
[runtime] 2022-06-28 05:32:06 [verbose]: ✔️ 22 repetitions
[runtime] 2022-06-28 05:32:06 [verbose]: Received 6 new frames (total 91 of 132)
[runtime] 2022-06-28 05:32:06 [verbose]: Received 6 new frames (total 97 of 133)
[runtime] 2022-06-28 05:32:06 [verbose]: Received 6 new frames (total 103 of 134)
[runtime] 2022-06-28 05:32:06 [verbose]: Received 6 new frames (total 109 of 135)
[runtime] 2022-06-28 05:32:06 [verbose]: Received 6 new frames (total 115 of 136)
[runtime] 2022-06-28 05:32:06 [verbose]: Received 6 new frames (total 121 of 137)
[runtime] 2022-06-28 05:32:06 [verbose]: 🔸 Step #3 start failing sends
[runtime] 2022-06-28 05:32:06 [verbose]: Received 6 new frames (total 127 of 138)
[runtime] 2022-06-28 05:32:06 [verbose]: 🔸 Step #4 wait for send attempts
[runtime] 2022-06-28 05:32:06 [verbose]: 🔸 Step #5 frames did not increase
[runtime] 2022-06-28 05:32:06 [verbose]: 💥 Failed
[runtime] 2022-06-28 05:32:06 [verbose]: ⏳ Currently loading components (0)
[runtime] 2022-06-28 05:32:06 [verbose]: 🧵 Task schedulers
[runtime] 2022-06-28 05:32:06 [verbose]: LoadComponentsAsync (standard) concurrency:4 running:0 pending:0
[runtime] 2022-06-28 05:32:06 [verbose]: LoadComponentsAsync (long load) concurrency:4 running:0 pending:0
[runtime] 2022-06-28 05:32:06 [verbose]: 🎱 Thread pool
[runtime] 2022-06-28 05:32:06 [verbose]: worker: min 1 max 32,767 available 32,766
[runtime] 2022-06-28 05:32:06 [verbose]: completion: min 1 max 1,000 available 1,000
[runtime] 2022-06-28 05:32:06 [verbose]: Host execution state changed to Stopping
```
https://teamcity.ppy.sh/buildConfiguration/Osu_Build/811?hideProblemsFromDependencies=false&hideTestsFromDependencies=false&expandBuildTestsSection=true
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
I can't find a better way to do this. It's very hard to trigger an
actual failure in the import process these days. For now I've just made
this work with the new assumptions. May be worth removing the test in
the future if this ever backfires.
