This is a prerequisite for https://github.com/ppy/osu/pull/25480.
The `WebSocketNotificationsClient` was tightly coupled to chat specifics
making it difficult to use in the second factor verification flow.
This commit's goal is to separate the websocket connection and message
handling concerns from specific chat logic concerns.
Them being together always bothered me and led to the abject failure
that is `APIUser` and its sprawl. Now that I'm about to add a flag that
is unique to `/me` for verification purposes, I'm not repeating the
errors of the past by adding yet another flag to `APIUser` that is never
present outside of a single usage context.
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.
This handles the case where on initial API connection, the server
responds with an `Unauthorized` response. It doesn't perform this same
checking/handling on every API request, which is probably what we want
eventually.
Opting to not address the full issue because I know this is going to be
a long one (see
05c50c0f6c/osu.Game/Online/API/APIAccess.cs (L233)).
A null there indicates a deserialisation error and therefore due to the
catch block immediately succeeding the changed line everything will
continue to work as intended.
These can occur when a network connection is completely unavailable (ie.
host resolution failures are occurring). Currently these would appear as
important errors which spammed the notification overlay every retry
forever, while no network connection is available.
I also took this opportunity to remove a lot of `bool` passing which was
no longer in use (previously the fail count / retry process was
different to what we have today).
