Currently, there's a period where the API is `Offline` even though it is
about to connect (as soon as the `run` thread starts up).
This can cause any `Queue`d requests to fail if they arrive too early.
To avoid this, let's ensure the `Connecting` state is set as early as
possible.
I noticed in passing that in a very edge case scenario where the API's
`run` thread doesn't run before it is loaded into the game, something
could access it and get a guest `LocalUser` when the local user actually
has a valid login.
Put another way, the `protected HasLogin` could be `true` while
`LocalUser` is `Guest`.
I think we want to avoid this, so I've moved the initial set of the
local user earlier in the initialisation process.
If this is controversial in any way, the PR can be closed and we can
assume no one is ever going to run into this scenario (or that it
doesn't matter enough even if they did).
It proved to be too difficult to deal with the flow that clears user
states on stopping the watching of global presence updates. It's not
helped in the least that friends are updated via the API, so there's a
third flow to consider (and the timings therein - both server-spectator
and friends are updated concurrently).
Simplest is to separate the friends flow, though this does mean some
logic and state duplication.
I managed to do this by accident three times today while testing using
the dashboard display, so it's time to action on it.
Touched on in
https://github.com/ppy/osu/discussions/30740#discussioncomment-11345996.
Was also mentioned recently in discord or another discussion explicitly
but I can't find that.
Queuing up requests on change to `api.LocalUser` is bad because the API
state is updated after `LocalUser` is updated, therefore we have to
schhhhhedullllllllleeeeeeeeeeeeeeee.
Though the code appears slightly different, it should be semantically
equivalent. APIUser equality is implemented on `Id` and `Host` should
never transition from non-null to null.
