Document CRDB `fully_consistent` nuances

[tstirrat15]

CRDB's fully_consistent can behave differently from other datastores by virtue of it being a distributed datastore. To wit:

• fully_consistent does not guarantee read-after-write in Cockroach.
• This is different from our other datastores and not well documented.
• Overlap strategy does not mitigate this. Overlap strategy prevents two writes from getting commit timestamps in the reverse order than they were observed actually happening in a client.
• This doesn't mean that cockroach doesn't normally have "read after write" consistency - it does - but we're bypassing that guarantee in fully_consistent requests because we don't let cockroach use the "latest" data it has. Instead, we pick a revision to evaluate at. That revision comes from cluster_logical_timestamp at request time which can be skewed from other nodes by up to max_offset. If the node picking the snapshot picks a timestamp older than was assigned to the write, your query won't see it even though the data is there on disk.

This is pretty niche, but is also potentially an unwelcome surprise for CRDB (and dedicated) users.