This time for `SocketException`s. I seem to recall looking at this and
deciding there was a reason to not catch socket exceptions, but on
revisiting it seems sane to do so.
This covers a fail case like reported:
```
2023-10-06 03:24:17 [verbose]: Request to https://lazer.ppy.sh/oauth/token failed with System.Net.Http.HttpRequestException: No such host is known. (lazer.ppy.sh:443)
2023-10-06 03:24:17 [verbose]: ---> System.Net.Sockets.SocketException (11001): No such host is known.
2023-10-06 03:24:17 [verbose]: at System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.ThrowException(SocketError error, CancellationToken cancellationToken)
```
Closes https://github.com/ppy/osu/issues/24890 (again).
In discussion with nanaya, we likely want this now that we're adding the
ability for some icons to be extended. Historically mod icons have been
displayed in a stable but arbitrary order (based on their position in
the `Mods` enum).
This change aims to make them stable across lazer scores (where they are
stored based on .. the order the user selected them).
With the way `dev.ppy.sh` was previously configured, the `osu-web`
`/multiplayer` routes and `osu-server-spectator` `/multiplayer` routes
would conflict with each other, with the `osu-server-spectator` route
taking precedence. This would mean that some `osu-web` pages would just
straight up not be available on dev.
To counteract this, the `osu-server-spectator` routes are now exposed
under `https://dev.ppy.sh/signalr/`. This PR updates the client-side
configuration to use these new routes.
This API endpoint is intended for usage with the entire `solo_scores`
machinery and ID schema, rather than the legacy `*_scores_high` ID
schema. It also supports automagically falling back to downloading
legacy replays if a stable-imported score is requested for download
(internally this happens via `legacy_score_id` in the `data` json).
This change will allow replays to be downloaded, but it will still not
yield 100% correct behaviour, as there is further work to be done in
that respect. The download tracker is expecting score hashes to arrive
from web to verify the integrity of the incoming download, but the API
does not expose such a facility right now; we will have to decide as to
whether we want to add one web-side, or whether we want to disable the
checking client-side.
This created weird cases in logs which are very hard to understand. The
one which really got me was this:
```
[runtime] 2023-08-13 07:48:27 [verbose]: Invalidating working beatmap cache for unknown artist - unknown title (Dummy)
```
Which looks like a dummy working beatmap was invalidated, but it turns
out that's just the local user which was populated when creating a new
local beatmap.
