feature request: Rework websocket keepalive pattern to reduce unnecessary data sending

[QuantumToasted]

What do you want to see?

Discord's "heartbeat" pattern seems more practical and makes more sense in the long term. Instead of putting the responsibility for keeping the websocket connection alive on the client, the server could instead request the client show it is still "alive" per se.

IIRC the flow is like so:

(Client: C Server: S)
C -> S: Identify
S -> C: Hello, etc
...
S -> C: Still alive? (heartbeat)
C -> S: Yes (heartbeat ack)

Then, instead of updating docs down the line to implore library developers to change their Ping intervals, that behavior can instead be changed on the server side to increase/decrease the heartbeat interval.

An example implementation of this would be introducing a new Bonfire event type, let's call it PingRequest:

{
    "type": "PingRequest",
    "data": 1700366134
}

data is obviously not required, but could be a Unix timestamp (or some other useful identifying information for clients including information such as why the Ping request was sent. Users would then be required to send a Ping within a certain timeframe before the server drops the WS connection.

As it stands, I'm not a fan of the current paradigm of shouting Ping events into the void needlessly when alternatives can reduce the number of events sent over the websocket connection. I'm unsure how often Discord sends heartbeat events, but 30 seconds to a minute seems like a good default.