This is still a workaround but arguably it's something we could leave in
place without much loss. I think this at least feels better than the
previous code.
Notably, you could argue the test coverage of the fail case is lower
since made it implicit that all tests will avoid the "backwards seek"
detections. But we never really had tests correctly- fail on the original
so I don't see any loss of value.
This fell out of my work on hit window-related replay issues. In my WIP
branch (that is probably going to get PR'd as draft soon) I refactored
`HitWindows` and found a few straggling test failures due to some places
reading hit windows for results that were not actually supported by the
underlying `HitWindows` implementations, leading to returning garbage
(mostly zeroes).
Importantly, there is one actual usage in game code with impact here -
`TaikoModSingleTap` was attempting to read the hit window for MEH, when
MEH was never actually a valid hit result in taiko (OK is). This was a
result of a copy-paste oversight from osu!, specifically from
https://github.com/ppy/osu/blob/51cf835fb6300aca53b5b98143d606f64d7a4d49/osu.Game.Rulesets.Osu/Mods/InputBlockingMod.cs#L58
* Move steps from ctor to a separate basic test.
* Wait for barrage to complete in basic test, as not doing so polluted
state of other tests.
* Reset score processor after every test.
`CatchHitWindows` were a vestige from the past, and were not actually
used anywhere except for the hit error meter test, giving off an
appearance that the hit error meter was working properly.
`CatchHitObject` actually specifies empty hit windows.
We've seen multiple cases where DrawableHitObject are stuck in the lifetime management container
due to not implementing a judgement (meaning they are never "hit" or "missed"). To avoid this going forward
CreateJudgement() must be implemented and return a non-null judgement.
This fixes BananaShower and JuiceStreams in osu!catch.
This also makes HitObject abstract and cleans up convert HitObject implementations.