This time with less bugs. It turned out that the crash was due to a
synchronisation issue between the pending reads and the actual shard
polling mechanism.
Essentially the pending reads would be cancelled via a simple bool but
there would still be a pass left and thus we would have a single
pending read left before or after running the polling mechanism and
this would cause a race condition.
Now the pending read mechanism is properly waited for before returning
control back to the caller.
This adds:
* CategoryChannel, which represents a category
* Guild.by_category() which traverses the channels grouping by category
* Guild.categories to get a list of categories
* abc.GuildChannel.category to get the category a channel belongs to
* sync_permissions keyword argument to abc.GuildChannel.edit to sync
permissions with a pre-existing or new category
* category keyword argument to abc.GuildChannel.edit to move a channel
to a category
Raise after loop completes without returning with most recent values
for r, data. This is a bit less fragile than checking tries < 4, since
changing the retry count requires changing values in multiple places.
(There seemed to already be handling in the 502 retry, tries <= 5,
which always evaluated to true, e.g.)
Previously, once out of retries, we would always return None without
raising.
This won't NameError so long as we make at least one HTTP request.
This is a breaking change. No longer does Messageable.send have a
filename keyword argument, instead this is all handled through the
discord.File model. To upload many files you must specify a list
of discord.File objects.
There were some dead-locking issues that I suspect were due to the
way the global rate limit was handled. This changes it into a simple
Event that allows multiple coroutines to pass through instead of one
by one.
If a 429 was already hit somehow then we're no longer pre-emptively
rate limiting and we're going to end up having a race condition in
the lock/unlock cycle.
