feat(general): add heartbeat to websocket control

[Mmx233]

When neko runs behind an L3 or L7 load balancer, it may encounter TCP connection timeout issues. Sometimes the maximum timeout cannot be set to a very high value, causing neko to frequently reconnect. Moreover, I believe that setting too large a timeout value might result in the server retaining too many unused connections.

This PR adds the event client/heartbeat and ignores this event in the backend.

The heartbeat is configured through the environment variable NEKO_HEARTBEAT_INTERVAL or the configuration setting heartbeat_interval, with a default value of 120 seconds. When the value is less than or equal to 0, the heartbeat mechanism is disabled.

After heartbeat_interval is passed to the frontend via the system/init event, the frontend starts sending heartbeat events at regular intervals.

Tested with Images: mmx233/neko:base mmx233/neko:google-chrome

[m1k1o]

For v3 we already have heartbeat but it is not configurable - const in the code and it is sending pings from server to the client, therefore it would be great to have this feature ported to v3 as well.

I wonder if it actually makes difference for loadbalancers, whether client sends the heartbeat or server. Alternatively, client could just reply to ping event from server, and we could avoid passing the configuration value to the client,

Similarly how we do ping-pong for webrtc in v3 from client to measure latency.

[Mmx233]

For v3 we already have heartbeat but it is not configurable - const in the code and it is sending pings from server to the client, therefore it would be great to have this feature ported to v3 as well.

I wonder if it actually makes difference for loadbalancers, whether client sends the heartbeat or server. Alternatively, client could just reply to ping event from server, and we could avoid passing the configuration value to the client,

Similarly how we do ping-pong for webrtc in v3 from client to measure latency.

Regarding who should send heartbeats. From a product perspective, since the client is the consumer of the connection and is responsible for opening and closing it, and may suddenly disappear due to network issues without properly closing the TCP connection, the client should proactively maintain the connection by sending heartbeats. Additionally, from a technical standpoint, this approach can conserve more resources. Having the client send heartbeats can save one goroutine per connection. When using gorilla/websocket, the server only needs to set the HandshakeTimeout in the upgrader to automatically clean up unused connections:

upgrader: websocket.Upgrader{
	CheckOrigin: func(r *http.Request) bool {
		return true
	},
	HandshakeTimeout: time.Minute * 5,   // <--- add this line
},

Regarding the minimum heartbeat frequency required for the entire connection link, the client cannot determine this. Therefore, the heartbeat frequency should be set by the mainetainer of the server, rather than make it configurable in the client settings or writing it in the code.

In WebSocket, successfully receiving or sending a message without error already indicates that the connection is not in an abnormal state. Therefore, I believe the ping-pong mechanism is unnecessary. In addition, once read method of gorilla/websocket connection returns an error, ReadMessage and WriteMessage will no longer succeed, this will happen when either party initiates a connection close or the client exceeds the HandshakeTimeout. Therefore, it is unnecessary for the server to attempt sending ping messages anymore when the connection is returning errors. This means that in the scenario of maintaining a connection, there is no need to use the ping-pong mechanism. What we can do is sending heartbeat messages from one side.

https://github.com/gorilla/websocket/blob/5e002381133d322c5f1305d171f3bdd07decf229/conn.go#L1005-L1008

// Applications must break out of the application's read loop when this method
// returns a non-nil error value. Errors returned from this method are
// permanent. Once this method returns a non-nil error, all subsequent calls to
// this method return the same error.
func (c *Conn) NextReader() (messageType int, r io.Reader, err error) {

[m1k1o]

@Mmx233 thank you for the explanation. I ported the changed to v3 so we can get this merged.