The lack of this bricks chat completely due to newtonsoft
deserialisation errors:
2025-02-24 08:32:58 [verbose]: Processing response from https://dev.ppy.sh/api/v2/chat/updates failed with Newtonsoft.Json.JsonSerializationException: Error converting value "TEAM" to type 'osu.Game.Online.Chat.ChannelType'. Path 'presence[39].type', line 1, position 13765.
2025-02-24 08:32:58 [verbose]: ---> System.ArgumentException: Requested value 'TEAM' was not found.
2025-02-24 08:32:58 [verbose]: at Newtonsoft.Json.Utilities.EnumUtils.ParseEnum(Type enumType, NamingStrategy namingStrategy, String value, Boolean disallowNumber)
2025-02-24 08:32:58 [verbose]: at Newtonsoft.Json.Serialization.JsonSerializerInternalReader.EnsureType(JsonReader reader, Object value, CultureInfo culture, JsonContract contract, Type targetType)
Flushes are assumed to have already come from a definitive state change
(read: disconnection). Allowing the exceptions that come from failing
the flushed requests to trigger the `Failing` code paths makes
completely incorrect behaviour possible.
Because it'll fail anyway - there is either no username or no password.
The reason why this is important is that the block was also setting API
state to `Connecting`.
When API is in `RequiresSecondFactorAuth` state, `attemptConnect()` is
called over and over in a loop, with no sleeping, which means that the
scheduler accumulates hundreds of thousands of these delegates. Sure you
could add a sleep in there maybe, but it seems pretty wasteful to have
the `localUser.IsDefault` guard *inside* the schedule anyway, so this is
what I opted for.
It seems that right now these timeouts do not check for actual data
movement, which is to say if a user with a very slow connection is
uploading and it takes more than `Timeout`, their upload will fail.
For now let's set these values high enough that most users will not be
affected.
