Update framework

Implement legacy skin encoder (#38090)

This PR implements a full encoder for the legacy `skin.ini` format.

The primary goal here was to try as hard as possible not to remove any
relevant information in the `.ini` file. Irrelevant information like
comments or whitespace will be dropped.

My direct goal with this is to close
#35503. Having a full skin encoder
means that the skin rename operation can be implemented by decoding
`skin.ini`, changing the name on the decoded skin, and then re-encoding
`skin.ini`, which will replace the bolting-on of several redundant
`[General]` sections.

My *indirect* goal is that having this will in the future facilitate
being able to toggle `skin.ini` settings via the in-game UI and have
them persist to disk, but I do not intend to follow up on this
particular thread at this time.

Of particular note:

- Added `SkinConfiguration.IsLatestVersion` in order to be able to
distinguish whether to write out `2.7` or `latest` as the skin version.
- Stable gives the default `BarLineHeight` in mania configurations as
`1.2f`. For unclear reasons, lazer inlined this factor *at point of
direct usage* and specified the default as `1f`. Keeping this does not
allow to preserve encode-decode stability, but also doesn't seem to
match stable (which will use the ini-originating value over the default
with no signs of adjusting with the `1.2f` factor), so the inline
application of the `1.2f` factor is removed and the default of
`BarLineHeight` is set to `1.2f` instead.

  Traces back to #32151.
- Some properties are added to `LegacyManiaSkinConfiguration` to ensure
encode-decode stability and thus are also read by the relevant decoder.
They are marked as unimplemented.

Test cases added here were selected from a dump of 3,421 `skin.ini`
files provided by @RockRoller01
[here](https://discord.com/channels/90072389919997952/1094408191665770597/1516078038528426055),
as some of the last remaining failures in my run of fixes.

With the implementation as is, when running the encode-decode stability
test on the full dump, there are still 42 failures, which all trace back
to either:

- Having duplicate keys in the `.ini` (most often, specifying both
`Version: latest` and another version).
- Specifying non-opaque alpha in colours which do not allow non-opaque
alpha.

I think those are fine to break.

---------

Co-authored-by: Dean Herbert <pe@ppy.sh>

Allow using slider velocity control in toolbox to adjust velocity of …

…selection (#38106)

https://github.com/user-attachments/assets/8d5f94b2-d7b6-4418-a8c2-2fb85aa77bb3

---

RFC

I have received information from @peppy that in the course of
preparations for the next lazer changelog video, @pishifat has expressed
dissatisfaction with the operation of the slider velocity control added
in #37746. If I understood correctly, the
issue was that the slider velocity control in question did not attempt
to interact with the current selection of objects. @peppy has requested
me to attempt to fix it before the next lazer release.

This PR contains an implementation of allowing the slider velocity
control to adjust the velocity of all selected sliders, if any.

I am not particularly happy with the resulting code for this feature,
but I also do not have many better ideas. Despite my attempts at
streamlining the logic after the initial pass, the implementation is
still tricky because it attempts to do much magic, both in trying to
achieve unobtrusive operation and sufficiently informative visual state.

There are subtle details that may turn out to be unsatisfactory to
mappers in practice. For one instance, the following flow may be of
concern:

1. Start with no selection. In this state the velocity control follows
the last slider by default.
2. Choose a velocity value manually.
3. Select an object.
4. Deselect the object.
5. The velocity value chosen in (2) is dropped.

Such behaviours can be brought back if desired, but at cost of further
additional complexity of the logic of the feature.

Allow using slider velocity control in toolbox to adjust velocity of …

…selection (#38106)

https://github.com/user-attachments/assets/8d5f94b2-d7b6-4418-a8c2-2fb85aa77bb3

---

RFC

I have received information from @peppy that in the course of
preparations for the next lazer changelog video, @pishifat has expressed
dissatisfaction with the operation of the slider velocity control added
in #37746. If I understood correctly, the
issue was that the slider velocity control in question did not attempt
to interact with the current selection of objects. @peppy has requested
me to attempt to fix it before the next lazer release.

This PR contains an implementation of allowing the slider velocity
control to adjust the velocity of all selected sliders, if any.

I am not particularly happy with the resulting code for this feature,
but I also do not have many better ideas. Despite my attempts at
streamlining the logic after the initial pass, the implementation is
still tricky because it attempts to do much magic, both in trying to
achieve unobtrusive operation and sufficiently informative visual state.

There are subtle details that may turn out to be unsatisfactory to
mappers in practice. For one instance, the following flow may be of
concern:

1. Start with no selection. In this state the velocity control follows
the last slider by default.
2. Choose a velocity value manually.
3. Select an object.
4. Deselect the object.
5. The velocity value chosen in (2) is dropped.

Such behaviours can be brought back if desired, but at cost of further
additional complexity of the logic of the feature.

Fix options menu not toggling off when pressing f3 again (#37648)

Previously pressing f3 again when the options menu was open would just
open it again. This code changes the Action from always showing the
popover to closing it if it is already open.

As noted in the original issue, framework changes were also required for
this to work. You can find the separate pr
[here](ppy/osu-framework#6743).

Was unsure if tests were necessary for a fix with minimal changes like
this, please let me know if you would like me to add some!

Fixes issue #36331

Co-authored-by: Bartłomiej Dach <dach.bartlomiej@gmail.com>

Implement new score multipliers (#37967)

- Part of #37818

Updates score multipliers to latest proposals, and bumps replay version
ready for recalculation.

---

For anyone following along, **please wait for the incoming news post
before sharing this publicly**. This is intended for internal
development use at this point. There's still some time before these go
live.

---------

Co-authored-by: Bartłomiej Dach <dach.bartlomiej@gmail.com>

Fix edge cases around matchmaking queue notifications (#37942)

Supersedes / closes #37881
Fixes #37497
Fixes #37214
Fixes #36744

## Some ranked play matches getting stuck in the database

This is an issue I've been investigating for a while now, and I have
suspicions that it's related to the following sentry event:
https://sentry.ppy.sh/organizations/ppy/issues/15519/events/7a0d5a390a2d4894ae382a1fdcfd54cc/

```
Unobserved exception occurred via FireAndForget call: Cannot join a multiplayer room while already in one.
```

While I haven't repro'd the exact failure case where `ends_at` is
`NULL`, it does put the game into a weird state:


https://github.com/user-attachments/assets/1d97cfbf-ae97-4f78-89bb-6b3f186c7c4e

Should be fixed by 787ef7f

## Game sometimes deadlocking when accepting queue invitations

I've personally experienced this when waiting for the invitation
notification to time out.


https://github.com/user-attachments/assets/cc191cbd-d72a-4a2e-a300-81f22b3fc993

Should be fixed by b238bf8

Fix edge cases around matchmaking queue notifications (#37942)

Supersedes / closes #37881
Fixes #37497
Fixes #37214
Fixes #36744

## Some ranked play matches getting stuck in the database

This is an issue I've been investigating for a while now, and I have
suspicions that it's related to the following sentry event:
https://sentry.ppy.sh/organizations/ppy/issues/15519/events/7a0d5a390a2d4894ae382a1fdcfd54cc/

```
Unobserved exception occurred via FireAndForget call: Cannot join a multiplayer room while already in one.
```

While I haven't repro'd the exact failure case where `ends_at` is
`NULL`, it does put the game into a weird state:


https://github.com/user-attachments/assets/1d97cfbf-ae97-4f78-89bb-6b3f186c7c4e

Should be fixed by 787ef7f

## Game sometimes deadlocking when accepting queue invitations

I've personally experienced this when waiting for the invitation
notification to time out.


https://github.com/user-attachments/assets/cc191cbd-d72a-4a2e-a300-81f22b3fc993

Should be fixed by b238bf8

Fix client not sending data relevant to replay to spectator server (#…

…37919)

- Related to #37818, but of no material
help to it at this point (too late for that)

As noted in
#37845 (comment).

Upon comparison of replays recorded by the client and by the server the
affected fields are: total score without mods, and the list of user
pauses. Additionally, the date of setting the score may differ -
server-side it seems to be written with UTC+0 while client-side it's
written using the local timezone offset. Not really interested in fixing
that last issue at this time.

Also included is an intentionally loud disclaimer in
`LegacyScoreEncoder` to tread with caution when treating the class. Not
sure it'll help, and it's a bit late for it as pretty much every single
versioning primitive has been ravaged to the brink of unusability, but
maybe it'll help someone in the future.

This also cleans up an unnecessary nullable on `FrameHeader.Mods` (added
in #30137). This change can be only done
if users on releases earlier than 2024.1023.0 can no longer connect to
spectator server. I leave it to reviewers to determine this as I have no
visibility over current spectator server configuration. Inspecting the
`osu_builds` table may help confirm this. If it provokes unease, I can
back this change out.

Fix client not sending data relevant to replay to spectator server (#…

…37919)

- Related to #37818, but of no material
help to it at this point (too late for that)

As noted in
#37845 (comment).

Upon comparison of replays recorded by the client and by the server the
affected fields are: total score without mods, and the list of user
pauses. Additionally, the date of setting the score may differ -
server-side it seems to be written with UTC+0 while client-side it's
written using the local timezone offset. Not really interested in fixing
that last issue at this time.

Also included is an intentionally loud disclaimer in
`LegacyScoreEncoder` to tread with caution when treating the class. Not
sure it'll help, and it's a bit late for it as pretty much every single
versioning primitive has been ravaged to the brink of unusability, but
maybe it'll help someone in the future.

This also cleans up an unnecessary nullable on `FrameHeader.Mods` (added
in #30137). This change can be only done
if users on releases earlier than 2024.1023.0 can no longer connect to
spectator server. I leave it to reviewers to determine this as I have no
visibility over current spectator server configuration. Inspecting the
`osu_builds` table may help confirm this. If it provokes unease, I can
back this change out.