Handle invalidated CRDT docs and apply updates correctly

[chriszarate]

What?

Handle invalidated CRDT docs and apply updates correctly. Companion to Automattic/vip-real-time-collaboration#31

Key change:

Even if a document has been invalidated (either by an out-of-band update or by restoring a revision), it is still the correct starting point to apply our changes.

There is no distinction between a document that has been invalidated by an "out-of-band" update and a restored revision. Both are invalidated and treated identically.

Note this TODO:

This new state should be persisted to the entity record. This
will result in a "dirty" record, but if the user does not save the
record, then content can be duplicated as other users join the session
or refresh.

If we have high confidence in our hash validation / invalidation, then
we could persist the updated record automatically. Or we could use
awareness states to let the user know that the content has changed on
the server and prompt them to save.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: chriszarate <[email protected]>
Co-authored-by: ingeniumed <[email protected]>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[ingeniumed]

This works well, and now the invalidation of the doc from an out of band update is reflected right after a refresh

[ingeniumed]

Feel like it's better to leave it as dirty, and let the user handle the save right now. Based on feedback and how the hash validation/invalidation turns out in testing we could issue the persist updated record action