Introduce a new internal type, SnowflakeList, which has better memory
footprint over a regular list or set of roles. It is suspected that
there will be a 9x reduction of memory for every Emoji instance and a
48 byte saving per Member instance. However, these savings will
probably only be evident on larger bots.
As a consequence of this change, Member.roles is now computed lazily.
Currently I am not sure if I want to do the initial sorting on the
SnowflakeList for Member, as this comes with a O(n log n) cost when
creating a Member for little purpose since SnowflakeList.has is not
overly relied on. If CPU time becomes an issue this might change.
In the docs, it says ``Note that bot accounts can only edit custom emojis they own.``
But after testing a bit. My bot was able to edit emojis in any guild that had the permissions `manage_roles`. Even if the bot didn't own the guild. Or was the original emoji uploader.
And I don't see any mentions of this in the API server or in the documentation. So I'm unsure how this ended up in here. It's possible I am misunderstanding the whole note. My bad if that's the case.
If the bot has access to the emoji, you can pass anything for its name
and it will work fine. The name is only required to be correct when
adding a reaction where you do not have access to the emoji,
all other cases ignore the name.
Due to a recent change in the Discord API, bots can now create
guild-specific emoji, so I've removed the parts of the documentation
referencing this restriction.
The global emoji cache still managed to somehow cause memory leaks. By
storing IDs directly and lazily evaluating them when needed this
essentially removes all strong references to Guild objects which would
cause an explosion in memory usage.
WeakValueDictionary cleans up too late and brings too little benefit.
Also clean up the state when the first READY is encountered for
AutoShardedClient and when any READY is encountered in regular Client.
