(Or local date, in the case of non-deployed builds).
Came up when I was looking at https://github.com/ppy/osu-web/pull/11240
and found that we were still hardcoding this.
Thankfully, this *should not* cause issues, since there don't seem to be
any (documented or undocumented) API response version checks for
versions newer than 20220705 in osu-web master.
For clarity and possible debugging needs, the API response version is
also logged.
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.
