add Sharding

[switchupcb]

This pull request implements #26 with the following changes:

• Session Refactor
• Session Manager Refactor
• Gateway Rate Limit Refactor*
• Shard Manager interface Refactor
• Shard Manager Implementation

*Tests for the Gateway Rate Limits were added in the commit 'add Gateway tests`:

• TestGatewayGlobalRateLimit in /wrapper/tests/integration/ratelimit_test.go: Sends 121 events using the Gateway rate limit.
• TestGatewayIdentifyRateLimit in /wrapper/tests/integration/ratelimit_test.go: Connects two sessions to the Gateway in a manner that tests the Identify Rate Limit.

However, TestGatewayGlobalRateLimit has been removed in commit 'remove TestGatewayGlobalRateLimit test' for the following reason:

• A heartbeat counts as a rate limited send event.
• The bot sends two heartbeats to the Gateway when connecting. The bot correctly stops sending events when 118 more send events are sent to the Gateway However, this means that the bot cannot respond to Heartbeats (without various workarounds).
• Therefore, the session is always disconnected before sending the last event.

[switchupcb]

The test originally failed due to an issue with the actual test. Once that was fixed, the issue is a data race occurring when one Session is writing to the *Client struct (e.g., bot.ApplicationID = ready.Application.ID) while another Session is performing a read operation (e.g., LogCommand).

So I must investigate the best way to handle this data race or declare it benign: It is most likely solved through heavy usage of an RWMutex.

[switchupcb]

Here is a solution to the issue above.

First, a quick recap on data race semantics within the disgo.*Client.

• Config elements are expected to be modified before the bot runs. Those that aren't maintain their own mutexes to perform distributed operations without issue.
• Handler operations are protected with mutexes.
• Sessions is only expected be modified by disgo and is set by the user at initialization.
• Authorization and authentication structs that pertain to the bot are typically only modified during initialization.

So these structs and their respective operations have sufficient data race protection.

The main issue with bot.ApplicationID is that it is referenced over 600 times.

• Logger usage.
• Error usage.
• Requests usage (in SOME endpoints).
• Not used in session except for logging purposes.

However, the field is only written to three times in the entire repository (including examples):

// from ./_examples/bot/main.go L#79 demonstrating that the field exists.
bot.ApplicationID = ""

// from ./wrapper/tests/integration/coverage_test.go L#57 setting the application ID for subsequent requests.
bot.ApplicationID = app.ID

// OFFENDING LINE: from ./wrapper/session.go L#327 setting the application ID for logging purposes.
bot.ApplicationID = app.ID

This situation leaves the following questions:

• Is referencing the bot's application ID necessary?
• What can we do about this issue?
• Is making this value an atomic operation worth it?
• Is sacrificing a test for this operation worth it?

Questions

Is referencing the bot's application ID necessary?

It is required for certain requests. So the user must have a way to store the application ID in the client.

What can we do about this issue?

There are a few options available:

1. Ignore it.
2. Remove the offending write.
3. Make the field atomic or use synchronization primitives (at the cost of logging performance and cognitive overhead for everyone involved).
4. Disable the data race detector for this test under the condition that it is benign.
5. Remove the test.

Is making this value an atomic operation worth it?

For two writes? No.

A user (developer) is expected to set the application ID before the application is running. Especially when the user is using an operation that — they know — requires an application ID.

The only operations that require an application ID are certain requests. In other words, APPLICATION ID IS NOT USED IN SESSION LOGIC (except for logging purposes): The main reason that it's included is in the rare case that the user decides to run two applications within the same codebase.

A user is only expected to run a single bot within a single time, even though running multiple bots is supported by disgo. So the real question: Does the application ID of the bot need to be set in the session code (when the ready event is received)?

• No, as it is used for logging purposes.
• No, because if the user needs that functionality (for requests) it would already be specified.
• No, because if the user follows the main example, it should be specified.
• No, because if the user is advanced enough to use multiple bots (for solely gateway operations), the user should be knowledgeable enough to specify this value for logging purposes.
• No, because if the user above does face issues with the code, the user can be told to include the application ID in each bot instance.

So remove the offending write.