Roadmap: make the library more resilient to the lack of cache

[kyranet]

Discord has released an intents system during early 2020. Later on, it stopped sending us DM channels during the READY dispatch.

On the other side, Discord.js was always built with the idea that its cache system would indeed be able to cache absolutely everything Discord sends us, and many things stood that way, for example it assumed that the channel data is readily available when a message is received.

And that's not the only thing, many things require the GUILDS intent to be always passed in order for many of the events to work. There's barely any event that is emitted without it. We could solve this with a Partials.Guilds, but that's far from ideal.

Nowadays with v13, if somebody wanted to receive messages from DMs, not only they would need to specify the intent (as required per Discord's docs), but they would need to find out that a second step is needed: specifying Partials.Channels.

Furthermore, not only we recommend setting cache limits to as low as 10 (to avoid some edge cases), but we also require channels to not be swept or limited because it otherwise breaks some things in the library.

Solution

After #6567 is solved, we will be able to build instances of our classes with ease and having a lower overhead, plus resolving any required resource eagerly (via getters in the instance) rather than early, this way a lot of checks are skipped.

We should also change the required checks to optional checks in our gateway handlers, as such that even if the guild or the channel for a resource is missing, it still emits the event.

Furthermore, for *Update events, we should be able to emit and just emit old as null if we are unable to retrieve the previous object from the cache. It might be wise to swap the order of those events from old: T, new: T to new: T, old: T | null.

With the three changes above, we are able to:

• Remove partial functionality: they bring a lot of overhead and require a lot of checks. This also transfers some of our responsibility back to the user, so how they handle that data is up to them (or to the framework they use). This also allows us to remove the edge case with DM messages, improving developer experience.
• Be able to sweep or limit channels, since they won't be required for the events to emit.
• Be able to not define the GatewayIntentBits.Guilds and still receive all events related to it (channels, members, bans...).
• Be able to disable caches entirely? Not confirmed, but in theory could.

Pitfalls (?)

Being able to finally limit roles and channels, as well as skipping the receival of guilds entirely, the library may not be able to compute getters such as the permissions ones, however, this proposal also delegates that responsibility to the user. If you are limiting the channel caches, the library won't be able to return accurate data, and as such, the developer is at fault for limiting said caches.

Documentation wise, we might need to write information notes that certain things require certain state in order to work, such as permissions getters requiring the guild with all the roles and channels to exist.

I'm unsure who needs to limits those caches anyways, but this is required for my next proposal anyways.