This is invariably a test fix but also a valid change to make in
isolation.
In short, the problem is thus: Now that the beatmap skin is hooked up to
realm to receive notifications about changed files (which is required
for correctly handling custom samples), tests started failing, because
of the following sequence of events
- Saving a brand new `.osu` to a beatmap set causes
`RealmBackedResourceStore` to fire subscription callbacks because a
new file was added to the set
- This fires `RealmBackedResourceStore.CacheInvalidated`
- Which fires `EditorBeatmapSkin.BeatmapSkinChanged`
- Which would previously fire `EditorBeatmap.SaveState()` and as such
mark the beatmap dirty / modified.
In this scenario this is gratuitous. There's no need to be raising save
states here, a new `.osu` was added to the set that is in a consistent
saved state and nothing actually changed in the beatmap.
However it does not appear sane to attempt to circumvent this with
conditional guards or something, because in cases where files are
added/removed from the set, *there isn't really any reason to take save
states anyway*. The change handler only deals with the `.osu`, any
modifications to any of the other files cannot be undone anyway.
Therefore, only keep the state save to the one change to beatmap skin
that *can* actually be sanely undone which is changing combo colours.
Among others, this features a scary-looking change wherein
`WorkingBeatmap` now exposes a `RealmAccess` via
`IStorageResourceProvider`. This is necessary to make
`RealmBackedResourceStore` actually start firing callbacks when the
edited beatmap's skin is modified by adding new samples to it.
This reverts to the way stable does things. Smooth seeking is nice and
all, but slows things down and doesn't give the instant reponse that
mappers are used to.
This should fix some performance issues regarding seeking as it no
longer tries to render large portions of the map during the seek
operation.
Note that I've also forced the summary timeline to always non-smooth
seek. It was bugging out in weird ways when doing smooth seeks and I
don't want to attempt to fix it.
I found this way too high in the editor, not giving enough feedback when
seeking.
To recap, this was put in place to avoid glitchy sounding audio. Such
glitchiness only occurs with *very* fast seeks. This is still well
within sane range.