Make conflict check atomic

[arriqaaq]

Potential correctness issue in conflict check

xuerong raised a potential correctness issue on Discord related to the conflict check logic. This may occur in the following scenario.

#373

The question concerns the validate_write_conflicts method in transaction.rs:

Inside this method, get_earliest_memtable_seq() is called, followed by check_keys_conflict(). However, there is no synchronized projection between these two operations.

Is it possible that another thread updates flushed_history (for example via flush_immutable_to_sst()) between these two calls? If that happens, check_keys_conflict() might run with a modified flushed_history instead of the one corresponding to the earlier state, which could potentially break transaction guarantees.

Example scenario

Thread 1	Thread 2
get_earliest_memtable_seq()
	flush_immutable_to_sst()
check_keys_conflict()

In this case, check_keys_conflict() would execute after flushed_history has been updated, meaning it may not be validating against the same state that existed when get_earliest_memtable_seq() was called.

This could result in the original flushed_history being replaced before the conflict check completes, potentially leading to an incorrect validation and violating transaction guarantees.