As we are finally pushing updates for this database, this adds a minimum
level of guarantee that a client will request a new version (without
having to worry about multiple levels of server-side caching).
Previously it was being scheduled another time each OnResume, resulting
in more and more calls as a user retries the same beatmap multiple
times.
To simplify things I've decided to just schedule once ever. This means
that on resuming there's no 400ms delay any more, but in testing this
isn't really an issue (load time is still high enough that it will never
really be below that anyway). Even if gameplay was to load faster, the
animation should gracefully proceed.
After hard-locking the mouse confine mode to `Always` in full-screen to
prevent confine issues from popping up, the confine mode dropdown in
settings had confusing UX due to seemingly having no effect when
full-screen.
The previous implementation of `SampleInfo`'s equality members was not
completely correct in its treatment of the `sampleNames` array. While
`Equals()` compared the values of `sampleNames` using `SequenceEqual()`,
therefore performing a structural check that inspects the contents of
both arrays, `GetHashCode()` used `HashCode.Combine()` directly on the
arrays, therefore operating on reference equality. This could cause the
pooling mechanism of samples to fail, as pointed out in #11079.
To resolve, change the `GetHashCode()` implementation such that it also
considers the contents of the array rather than just the reference to
the array itself. This is achieved by leveraging
`StructuralEqualityComparer`.
Additionally, as a bonus, an array sort was added to the constructor of
`SampleInfo`. This is intended to be a "canonicalisation" processing
step for the array of sample names. Thanks to that sort, two instances
of `SampleInfo` that have the same sample names but permutated will also
turn out to be equal and have the same hash codes, given the
implementation of both equality members. This gives `SampleInfo`
set-like semantics.
