The counter implementaiton is now list based, and will not invalidate
previous hits by removing them but by testing if they are within the 1
second span, allowing better integration with replays and spectators.
Previously was relying on whether `SaveReplay` returns null, but since
I've changed it to use the standard "prepare score for import" path, the
button has to check for local availability after import since that path
doesn't return null on fail.
Right now, the client does nothing to ensure a beatmap is in a valid
state before requesting to submit a score. There is further work to be
done client-side so it is more aware of this state (already handled for
playlists, but not for the solo gameplay loop), but the solution I have
in mind for that is a bit more involved.
This is not used server-side yet, but I want to get this sending so we
can start using it for some very basic validation.
Will resolve the basic portion of #11922 after implemented server-side.
I don't think this is necessarily a final solution (as this means all
HUD elements are adding overhead even when not visible), but this will
make the implementations much easier for the time being.
I've checked and can't notice any perceivable overhead in profiling so
we should be fine for now.
It is an expectation of users that when the HUD is shown after a period
of being hidden, it will visually reflect the state based on recent
judgements.
To achieve this, I've added `AlwaysPresent` and moved the transform
application to the meter level, rather than at a child level. If this is
seen as a bad direction, `AlwaysPresent` can be applied to the drawable
children and the transforms can be moved back.
Also of note, `ColourHitErrorMeter` is pretty weird. The flow class
could potentially be removed and reduce `AlwaysPresent` usage by one.
Can do that refactor as part of this PR if preferred.
Closes#18624.
