Because submission can be prevented by both not having been issued a
correct submission token, and by not actually registering any hits in
gameplay, ensure that tests that don't receive a token register at least
one hit, to avoid potentially having test cases that test the "no token"
flow pass erroneously because they never had any hits in the first
place.
Due to the lack of locking, there was a chance the the update thread
`context` was retrieved just before the `flushContexts` call, followed
by `.Refresh()` being run while the blocking behaviour was invoked.
This can be seen in test failures such as
https://ci.appveyor.com/project/peppy/osu/builds/39859786/tests.
As an aside, I tried multiple different methods to avoid `lock()` on the
update thread but they felt flaky. The overhead of lock when there's no
contention is reportedly around 30-50ns, so likely not of concern. We
can address it at a later point if it becomes one.
I am aware there are more throughout the codebase but intentionally left
the remaining mentioned for one reason or another. The intention here is
to mainly change user-facing versioning to change the positioning of the
"lazer" term (to be where we would expect "cuttingedge" or "beta" to
be).
The stacking code currently uses an unseeded RNG and there is a non-zero chance the stack will be very flat (small Y position difference).
Technically, `RNG.NextSingle(0, 5)` can return `0`, but extremely unlikely that the all RNG calls return 0.