This resolves a bug where disconnecting the socket client would not
actually close the websocket. Bots would appear to remain online in the
discord client until their connection to discord eventually timed out.

The underlying cause of this issue sourced from the cancellation token
passed into the websocket's ReceiveAsync method - when entering the
disconnect process, the first step is to cancel out all of the
connection tokens. Unfortunately, the standard ClientWebSocket handles a
token cancellation by aborting the socket, rendering it inoperable for a
safe closure.

This change removes the inner cancellation token passed into
ReceiveAsync. The cancellation token is still retained for use in the
receive loop, so the receive task should gracefully complete once some
event satisfies the ClientWebSocket's blocking receive.

To ensure that all clients succesfully close, regardless of their
traffic, the disconnect procedure was rearranged such that awaiting the
receive task now occurs last, after the socket has been closed. Closing
the socket will propagate an event up to the ClientWebSocket's receive
method, which will allow the loop to iterate and gracefully complete.

So far, I have validated this change against basic connection opening
and closing, for both the gateway and voice clients. I have not yet
validated against unplanned connection interruptions, though I believe
that this change might actually improve some of those connection bugs,
since the ClientWebSocket should never find itself in an aborted state.