This wraps the closing behavior in a task. Subsequent callers of
.close() now await that same close finishing rather than short
circuiting. This prevents a user-called close outside of __aexit__ from
not finishing before no longer having a running event loop.
Some of the logs were only useful for debug scenarios, so they have
been downgraded to DEBUG. Others were in INFO but supposed to be in
WARNING so those were upgraded.
This results in poor ergonomics due to the lack of default generics
for the common case. For most users this ends up in a degraded
experience since the type will resolve to Unknown rather than at the
very least a Client.
This is mainly for low level decision making for utilities that need
to know whether to fetch a member by HTTP or to query through the
websocket.
The library already does this trick in some places so it's only fair
that end users possess the same ability as well.
This should work both on Windows and on Linux.
Apparently these types of blips are considered normal for Discord. So
rather than letting the reconnect logic handler expect these to be
catastrophic, it should handle it specially so it doesn't waste an
IDENTIFY for what ultimately should just be a small networking blip.
This also makes it less noisy for the end-user as these complaints
happen from time to time.
Previously if a disconnect happened the client would get in a bad state
and certain shards would be double sending due to unhandled exceptions
raising back to Client.connect and causing all shards to be reconnected
again.
This new code overrides Client.connect to have more finer control and
allow each individual shard to maintain its own reconnect loop and then
serially request reconnection to ensure that IDENTIFYs are not
overlapping.