Log a fatal exception when the WebSocket cannot be recovered
This resolves#883.
The previous behavior when the WebSocket was closed with a 4006
(invalid state) was to kill the reconnect task and log an exception.
While this behavior is 'correct', it does not make it obvious to the
user (or developer, in my case) as to why their client has just quit and
not bothered to attempt a reconnect.
The current best way to determine if the client needs to be reset is to
check that CloseCode property on the WebSocketException is set to 4006.
However, since Discord does not have close code 4006 documented, it
feels like only half of a solution.
This change allows users to opt-out of fatal invalid-states in the
client's configuration - though it is discouraged. If they have not
opted out of them, a 4006 will trigger a FatalException, which can then
be caught with a more simple pattern match in the Log event.
This change also expands what we consider to be a fatal close code, and
will raise a FatalException for a 1000 (Discord should never close a
connection for us), 4004 (invalid token), 4010/4011 (shard related).
/// Gets or sets the max number of users a guild may have for offline users to be included in the READY packet. Max is 250.
/// </summary>
public int LargeThreshold { get; set; } = 250;
/// <summary>
/// Gets or sets whether a State Invalidation from Discord should be fatal. Setting this to false could lead to unexpected behavior when Discord is unstable.
/// </summary>
public bool InvalidStateFatal { get; set; } = true;
/// <summary> Gets or sets the provider used to generate new websocket connections. </summary>
public WebSocketProvider WebSocketProvider { get; set; }