Test was added in 5495c2090a to exercise a
previous version of the hotfix-workaround of not allowing seeking back.
Now that the hotfix-workaround also encompasses seeking *forward*, which
breaks another 100 tests, thus requiring the hotfix-workaround to be
turned off for tests, this situation is just completely out of
control. So I'm just removing the test because ugh.
Probably closes https://github.com/ppy/osu/issues/34645.
Obviously this is only good if the score has managed to process online
and slot into a leaderboard before the user requested a retry. I can't
make miracles happen.
Notably this is not applied to quick retry, because it would make quick
retry slower, and the presumption is that if the user is quick-retrying
their last score is likely useless for global leaderboards anyway. (The
one exception to that last part is possibly quick-retrying from results
screen, which is a flow that we have, but maybe fine to ignore it...?)
This is super haphazard in the first place but I'm going to look past
that for now.
Basically, due to the order of operation, the tags could be initialised
via `updateTags()` before the perform search action was initialised,
leading to clicks doing nothing.
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.
Other textual keyword filters also worked like that, wherein if you did
`artist=a artist=b` the second filter would overwrite the second, but in
those cases the query is against a single field, so attempting to put
multiple search criteria in conjunction on a single field is kind of
nonsensical, so it was sort of fine to do that.
Which is not the case for user tags, which are multi-valued.
Because of greedy matching, a filter of
tag="style/clean"! tag="song representation/simple"!
would not parse into 2 separate filters like
(tag, =, "style/clean"!)
(tag, =, "song representation/simple"!)
but rather a single one like
(tag, =, "style/clean"! tag="song representation/simple"!)
This sort of matches what web did in
https://github.com/ppy/osu-web/pull/12044, except web does some stuff
with quote escaping that I'd rather not, and also the search syntax
seems to slightly deviate because web seems to be using single quotes
and double quotes to open the value part of the filter. I'm not sure
what the difference is and I'd rather not go into all that right now.