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.
This uses the nonce field to properly disambiguate queries. There's
also some redesigning going on behind the scenes and minor clean-up.
Originally I planned on working on this more to account for the more
widespread chunking changes planned for gateway v7 but I realized that
this would indiscriminately slow down everyone else who isn't planning
on working with intents for now.
I will work on the larger chunking changes in the future, should time
allow for it.
This prevents our sessions from being invalidated by Discord which
caused a lot of failures when resuming. This caused an unnecessary
amount of IDENTIFYs to happen depending on the circumstances.
Closes#2631
See also discord/discord-api-docs#1472
Probably not a significant difference but might as well use it here.
The basic idea is to cache the getattr calls instead of repeatedly
doing it (since they're around 105ns on my machine). The dictionary
lookup is about 41ns on my machine.
The next step in speeding up library code some more should be in
the parser bodies themselves but that's a problem to tackle another
day.
