[Feature/Discussion] Expose more low-level APIs, remove "internal" access modifier from DiscordRestApiClient

[eesquibel]

Expose more low-level APIs, remove "internal" access modifier from DiscordRestApiClient, among others.

I may be missing the background to this, but there seems to be a preference toward internalizing a very large set of the backend APIs used by the Discord.NET project.

This really limits the use for the library in more creative use-cases.

My personable example:

• My project is split into a series of workers each running in a container (Docker).
• The primary work interacts with Discord directly and in the SlashCommandExecuted event, it adds the user-requested command to an external queue (RabbitMQ) and tells the Discord API the processing of the command is deferred (via SocketCommandBase.DeferAsync).
• A second worker consumes the queue messages and processes the slash command
  The underlying design goal is for the worker container that interacts with Discord to be unconcerns by the exact implentation of each slash command, ergo each command being the responsibility of a separate worker.

Unfortunately, there is no direct way via the Discord.NET public APIs to update the interaction response outside of the initial SlashCommandExecuted event handle as all the associated classes either have internal constructors, or the underlaying service classes that execute the webhooks/{application}/{token}/messages/@original requests are themselves marked at internal.

I would love to see more of these low-level APIs exposed so more creative use-cases for the library can be used and not limited by such an opinioned design framework.

[csmir]

Discord.Net holds the hands of the developer in getting and using entities by design. While the idea is wonderful, it very much does the opposite of what Discord.Net actually intends to be. I will move this to a discussion and request a followup of other contributors.

[AddressXception]

Hey, great project.

I have a similar use case where the application context that initially responds with DeferAsync might not be in the same process (or even on the same machine) as where the background processing happens. It's a challenge to have to hold onto the object in memory where the client is initialized while background processing happens, and then marshal the result back to the original app process in order to follow up.

If these internal constructors were exposed, or there were some other straightforward way to cache/serialize/rehydrate state, it would significantly simplify my code & would also be more fault tolerant since we'd be able to survive a process restart, or some other system event like a pod getting evicted from a cluster, etc.

I can definitely appreciate wanting to keep things simple. Normally I'd just fork the code and expose what I need, but I haven't been working with this lib for very long and I'm curious if there are perhaps some other unintended consequences of allowing consumers of this library to cache and rehydrate state manually?

[AddressXception]

After some digging, it appears this is already captured in issue #2238 and PR #2251 but it looks like progress on this stalled out in May of 2022. Is this stuff still on the roadmap?