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).
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.
```csharp
[network] 2022-09-26 18:18:39 [verbose]: Processing response from https://dev.ppy.sh/api/v2/me/ failed with Newtonsoft.Json.JsonSerializationException: Error setting value to 'rankHistory' on 'osu.Game.Online.API.Requests.Responses.APIUser'.
[network] 2022-09-26 18:18:39 [verbose]: ---> System.NullReferenceException: Object reference not set to an instance of an object.
[network] 2022-09-26 18:18:39 [verbose]: at osu.Game.Online.API.Requests.Responses.APIUser.set_rankHistory(APIRankHistory
value) in /tmp/osu/osu.Game/Online/API/Requests/Responses/APIUser.cs:line 231
```
This is already handled amicably by the `Failing` -> `Connecting` flow.
Having this set in `handleRequest` throws things off, potentially
leading to the `Online` state change before the user has been populated.
This isn't really required as such, but feels more correct. There was no
reason for it to wait for the friend population to complete before
deeming things to be "online".
This allows for various components (like gameplay) to obtain a correct
username even if the API is not yet in a connected state. The most
common case is during startup, where a connection may not have been
established yet, but the user's username was restored from their config
file.
By making the change, local scores will now have the correct username
(although avatar etc. will be missing, which I think it fine) even if
the API is not yet connected. Previously, they would show up as "Guest".
All usages of this are made with the intention of showing data when an
api is going to eventually become available. In the case of a login
failure, components are also able to display a correct state.
With this change, it makes online components display in a more correct
state during startup or initial logging in phase.
