When typing continuously, there is always a pending op present.
The only time we're not saving is if the inflight op isn't changing.
So long as this has changed, it means the previous one has been processed.
The meta.source of an update is populated on the server side so
we need to keep our local connection id up to date with it. When a duplicate
op is submitted we must send all possible client ids that it could have
been sent with.
If we do not get a reply from the server acknowledging our update after 5 seconds,
send it again. If it never got to the server, this is like normal. If the update
got to the server, but we never received the ack then we need to rely on ShareJs's
duplicate handling. We set the dupIfSource parameter on any retried updates which
let ShareJs know that it's a dup if we already have an op with this version number
and client id. The doc-updater and real-time services need changes to correctly
send another ack only to the submitting client in the case of a duplicate update.
Add in 5 second delay between flushing updates when only a single user
is editing a document. As soon as an update is received from another user
we switch to sending updates immediately again so there is no latency
between collaborators. The logic applies to individual docs, so two users
can be editing different docs and will still buffer updates since they
will not affect each other.
