SplitOperations may undo committed changes

There is a race condition when SplitOperations identifies garbage on a document. The feature was introduced with OAK-2421.

The issue occurs if the following sequence of operations happens on a document:

• The document is updated with e.g. _deleted.rX-0-1 = false within Commit.applyToDocumentStore()
• Commit.createOrUpdateNode() perform the update and calls checkSplitCandidate(). The document becomes a split candidate, because it is over the threshold of 8kB
• At the same time a background update is running and starts to look at the split candidates.
• The background update looks at the document and calls SplitOperations.collectLocalChanges(). At this point _deleted.rX-0-1 = false is not committed and doc.isCommitted(rev) returns false
• The commit proceeds, updates the commit root and sets the new head revision
• The background update now calls SplitOperations.isGarbage(rX-0-1) and the method will return true!
• The background update then removes _deleted.rX-0-1 = false together with the _commitRoot entry