I'd have preferred a `get; init;` property but tests were also attached
at the hip to the public bindable. Without some extra composition this
is the best that I can do.
This is a prerequisite for supporting skinning of leaderboards.
- New `IGameplayLeaderboardProvider` and `IGameplayLeaderboardScore`
interfaces are introduced. They are strictly concerned with supplying
leaderboard data.
- Logic of managing display, which was previously jammed into the
inheritance hierarchy of `GameplayLeaderboard`, is now moved into
`IGameplayLeaderboardProvider` implementations. Solo play,
multiplayer, and multiplayer spectator get their own implementation of
the interface.
- The inheritance hierarchy of `GameplayLeaderboard` and per-player
overriding of the implementation of the gameplay leaderboard is gone.
Only one drawable class (renamed to `DrawableGameplayLeaderboard`) is
allowed to display the leaderboards, across all modes of play.
This is in response to
https://osu.ppy.sh/community/forums/topics/2058708?n=5, wherein the user
is having a problem with joining multiplayer, but I have basically no
diagnosing capabilities, because the logs are all
2025-03-26 18:57:57 [error]: Failed to join multiplayer room:
2025-03-26 18:58:40 [error]: Failed to join multiplayer room:
2025-03-26 18:58:41 [error]: Failed to join multiplayer room:
2025-03-26 18:58:41 [error]: Failed to join multiplayer room:
which appears to originate from
https://github.com/ppy/osu/blob/c82eaafe98d96b9f49a4a7f168ef5c484e67d76f/osu.Game/Screens/OnlinePlay/Multiplayer/MultiplayerLoungeSubScreen.cs#L91
Now, as far as I can tell, there are two possibilities here:
1. The exception's `Message` is null or empty. That's not exactly great
or typical, but sure, this could possibly happen - in which case the
error logging is silently eating whatever little relevant detail
there is left to use.
2. The exception is *actually* `null` itself, and we're in the X Files.
This PR is intending to defend against (1).
In examining the logging further, I also spotted the following issues:
- In the single path that specifies a custom failure handler (which is
`DrawableLoungeRoom` which handles joining a passworded room), the
custom failure handler being present means that the error would be
presented to the user, but it would not be logged. At all.
- In playlists, if the exception for whatever reason had an empty
message, an empty notification would get posted. And in general to me
it feels a bit dodgy to be directly presenting exception notifications
to users without any preamble, hence the added "Failed to open
playlist" prefix.
Removes storage of `selectedBeatmap` that was referenced through
multiple class-level methods.
To expound a bit, this structure felt better (or otherwise passing
`APIBeatmap` through methods) alongside removal of the `#nullable
disable`, otherwise each method would check `selectedBeatmap != null`.