Optimistic concurrency allows Fractured Read

[aphyr]

Building on #17927, it appears that transactions executed with optimistic concurrency allow G-single: read skew. Here's an example test run: in five minutes it recorded hundreds of instances of G-single, G-nonadjacent, and G2-item. These anomalies are prohibited under Serializability, Snapshot Isolation, Repeatable Read, and Consistent View. For instance, here's a G-single case involving a read-write / write-write cycle between two transactions:

The top transaction, T1, read key 1060 and saw its value was [2]. It went on to append 5 and 6 to key 1093. The bottom transaction, T2, appended 3 to key 1060; from the read of [2], we know that T2's first append must have executed after T1's first read. T2 went on to append 3 to key 1093, and then read key 1093's state as [3]--which tells us that T2 performed the first write to key 1093. From this we know that T1 must have appended 5 to key 1093 after T2 appended 3.

Here's a fractured read, in which top transaction T1 appends a value to keys 271 and 279, and bottom transaction T2 observes the write to 279 but not 271. This is forbidden under Read Atomic, and by extension Update Atomic, Causal, Prefix, Parallel Snapshot Isolation, and generalized SI.

[ayende]

This is essentially a duplicate of #17928, given that I believe they have the same root cause. Full answer is there.

[arekpalinski]

We have updated our documentation and provided more clarifications when talking about transactions in RavenDB and the Client API Session.

The actual changes we made can be reviewed here: ravendb/docs#1766.