Fine-tune the realtime auto-save to prevent losing unsaved content

In the end I implemented this:

• Push / propagate the local state (for content and auto-saver) immediately when the visibility of the DOM document changes to hidden (i.e. when the user switches the tab / window, or closes the tab / window or navigates away).
• Store unsaved local changes in the browser session storage before the document gets hidden, and restore (possibly with a 3-way merge) the unsaved changes from the session storage when the user joins back the realtime collaboration session.

This code comment explains the decision:

Push unsaved changes to the session storage when the page becomes hidden. We don't save because it can lead to a merge conflict that would not be seen and resolved until the page is visible again (blocking the save for the other realtime collaborators in the mean time). Even if we save by forcing an overwrite, we might not be able to propagate the new version (that we get in the response) to the other collaborators (e.g. if the page was hidden because the user navigated to a different page or closed the browser tab), which would lead to a merge conflict on their side. Moreover, saving whenever the user switches to a different tab affects our automated functional tests which rely a lot on tab switching. Last but not least, we could have multiple users leaving the collaboration session at the same time, e.g. at the end of a meeting, which would lead to many revisions overwriting each other. Ideally, we would have an "auto-save" bot server-side that connects to the realtime session and uses its own ChainPad instance to reconstruct the content from the received patches, but it's not easy to run ChainPad (JavaScript) code server-side.