Implement client-side and server-side transformation optimisations to reduce latency-induced update consistency clashes

[Luna-Klatzer]

Due to the current structure of the OT system all updates which are performed in the local editor are shipped immediately to the remote as single updates, which increases the likelihood of clashes and inconsistencies due to misplaced edits and updates. Given the risks of such updates messing up the file content we have to optimise the update stacks and reduce the likelihood of errors.

On the client side, updates should be pooled and only sent once the previous update has been acknowledged and updated. This should allow the updates to be reduced down to the essentials and what the connection can handle, as each update will take exactly 2x latency + processing time and will naturally slow down if the internet connection is worse, increasing the update rate per sent websocket message and reducing lag.

On the server side, updates might arrive with incorrect time stamps and incorrect positioning. To handle this, we should implement a pool which naturally pushes updates every two seconds to the stored content on the server and the other connected clients. Using this method all received updates will be sorted appropriately with the client-side generated timestamp and fix any errors that occurred during transport and will be appropriately applied locally and to the other clients.

Additionally, to ensure the client stays up-to-date with the server, we should introduce forced reloads which refresh the page, the local OT stack and the state of the server and allow the local user to work with the state that the server actually remembered. This is simply a measure to reduce the likelihood of the server and local state being out of sync by practically resetting the chances every 30 minutes or so. Using some sort of loading screen or announcement we can block the user from typing for a few seconds while the page reloads.

[Luna-Klatzer]

Implemented client-side optimisations with the merge of #280. Server-side optimisations are likely not necessary and so left out for now.