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 has potential to be a breaking change and Discord could definitely
royally screw this over in the future. However, as far as I can tell
every interaction has either a User or a Member so this change should
be kosher. I'm unaware of any interaction, even in the future, where
this is not true.
I hope these are not my famous last words.
This reduces some repetition in many functions and is ripped out of
the webhook code. This also removes the unused HTTP functions for
interaction responses since those belong in the webhook code rather
than the HTTPClient.
The first issue involved copied users which would lead to user updates
causing faster evictions of the cache than was expected.
The second issue involved users that weren't bound to an internal
lifetime eviction policy. These users would not get evicted.
For example, a user without mutual guilds or being part of the internal
cache in general (messages, DMs) would never end up being evicted for
some strange reason. To handle this case, store_user would get a
counterpart named create_user which would create a user without
potentially storing them in the cache. That way only users with a
bound lifetime within the library would be stored.