Netflux server-side idle timeout is hardcoded at 65s and kills healthy realtime sessions in throttled background tabs (server-side counterpart of XWIKI-23928)

Thanks for the detailed measurements Kenan Alci. Here's how this is fixed.

Server-side WebSocket pings
Raising the server idle timeout would only push the problem further out, because the client's own PING messages are sent from JavaScript timers that the browser throttles in background tabs. Instead, the Netflux server now sends WebSocket ping frames to every connected client (every 25 seconds by default). Browsers answer these ping frames themselves, without involving any JavaScript timer, so the answers keep arriving at a steady rate no matter how long the tab has been in the background or how hard the browser throttles it. The realtime editor in xwiki-platform-yjs already works this way.

A client that stops answering (closed laptop, lost network, crashed browser) is disconnected after 3 consecutive unanswered pings, i.e. 100 seconds after its last answer with the default settings.

Configuration
The hardcoded 65s value is gone. These properties can be set in xwiki.properties:

• netflux.maxIdleTimeout (default 75000): the WebSocket session idle timeout. On Tomcat and Jetty the server pings count as activity, so this timeout is not reached while the server keeps pinging; it is a safety net for containers that count only incoming messages.
• netflux.pingInterval (default 25000): the number of milliseconds between two server pings. Set it to 0 to disable the server pings. In that case, set netflux.maxIdleTimeout to at least 90000, because the client's own keep-alive messages are then the only activity, and background tabs send them only once per minute.
• netflux.pingMaxMissedPongs (default 3): the number of consecutive unanswered pings after which the session is closed.

Secondary observation (ENOENT on rejoin)
As you suggested, this will be tracked in a separate issue, because it needs its own investigation. This fix should already make it much rarer, since healthy background tabs are no longer disconnected. A likely cause: when the only user of a channel is disconnected, the server removes the channel, but some realtime components (the saver and the user data) try to rejoin using the old channel key.