The buttons don't check whether the operation they correspond to is
possible to perform in the current state of the selection box, so not
checking `Can{Reverse,Rotate}` causes superfluous undo states to be
added without any real changes if an attempt is made to reverse or
rotate a selection that cannot be reversed or rotated.
The code here was assuming that if the beatmap which is having changes
copied across does not exist within the `BeatmapSet.Beatmaps` list, it
was not yet persisted to realm.
In some edge case, it can happen that the beatmap *is* persisted to
realm but not correctly attached to the beatmap set. I don't yet know
how this occurs, but it has caused loss of data for at least two users.
The fix here is to check realm-wide for the beatmap (using its primary
key) rather than only in the list. We then handle the scenario where the
beatmap needs to be reattached to the set as a seprate step.
---
This does raise others questions like "are we even structuring this
correctly? couldn't a single beatmap exist in two different sets?"
Maybe, but let's deal with that if/when it comes up.
Firstly, this is intended to be a float division.
Secondly, dividing integers by 0 results in an exception, but dividing
non-zero floats by 0 results in +/- infinity which will be clamped to
the upper range.
In particular, this occurs when the beatmap has 1 hitobject (0 drain
length).