feat(transaction): implement the remaining drafted actions

[wjones127]

Stacked on the index-actions PR. Implements the four actions the Transaction V2 draft still listed as unwritten — AddOverlays, RefreshRowVersionMetadata, UpdateCompactedSsTables, and AssertUniqueKeys — plus the lowering of the three legacy operations that map onto them: DataOverlay, UpdateMemWalState, and the vertical form of Update. With this the implemented vocabulary covers the whole draft. No format change: the wire shapes land in #7954.

Supersedes #8632, whose head was on a fork and so could not be part of a GitHub stack.

Three of the four actions are ordinary deltas. The fourth, AssertUniqueKeys, is the first thing in the vocabulary that is a precondition rather than a change: it carries the filter of key hashes a merge insert is about to insert, so that two concurrent inserts can be shown not to collide. Nothing in the manifest records which keys exist — the key columns are an unenforced primary key — so the filter has to travel with the operation, because it cannot be recovered from any post-image.

Example

Appending rows and asserting their keys are new, in one commit. If a concurrent commit inserted rows without saying which keys they carry, this one is rejected, because there is nothing to compare against:

CompositeOperation::new(vec![UserAction::new("insert new customers", vec![
    Action::AddFragment(AddFragment { local: 0, physical_rows: 500, .. }),
    Action::AddDataFile(AddDataFile { fragment: Ref::Local(0), file, .. }),
    Action::AssertUniqueKeys(AssertUniqueKeys {
        key_fields: vec![Ref::Committed(0)],
        filter: inserted_key_hashes,
    }),
])])

Conflict rules

Two of the new actions needed something the footprint could not previously express.

An overlay writes no coordinate at all. Overlays are appended, never replaced, and when two cover the same cell the newer committed_version wins — so two concurrent overlays must not collide with each other. What an overlay does need is for its fragment to still be there, which is a dependency rather than a write, and is now tracked as one.

A key assertion is not a coordinate either. The keys are user-supplied, so two writers can insert the very same key while writing it into fragments of their own — their coordinates stay disjoint however badly the keys collide. Uniqueness is a claim about values, not about structure. The footprint gained a row-insertion marker and the assertions themselves. Two sets are compatible when both say which keys they insert, over the same columns, and the filters provably do not intersect; an unqualified insert, different key columns, or filters built with incomparable parameters all leave the assertion unverifiable, which counts as a conflict. The marker is set by any AddFragment that is a data change, which over-approximates: the rows a merge insert updates arrive in a new fragment too and carry no new key, so two writers who only ever touched existing keys can still conflict.

Translating Update

Update translates in its vertical form — rows leaving the fragments they were in and arriving in new ones, which is a Delete and an Append in one step, plus the key assertion and the SSTable progress it carries. Its RewriteRows and RewriteColumns forms are rejected, for the same reason Merge and Project are: what they mean depends on what the read version holds, and the translation only sees the operation. Rejection falls back to the conservative always-retry, so nothing is approximated.

Behaviour differences from the legacy path

The legacy UpdateMemWalState arm of the manifest build never carries the read version's fragments into the manifest it produces, so committing it against a non-empty table empties it. The action path leaves the data alone, which is what the operation means. The parity test asserts both, so the difference is recorded rather than hidden; the legacy bug is untouched here.

A key assertion is compared symmetrically, so a plain append concurrent with a merge insert conflicts in both directions. The legacy check only runs from the retrying transaction's side, so an append that lands after a merge insert is currently allowed through and can introduce a duplicate key.

An update and a column rewrite of the same fragment no longer conflict. Which rows are gone and what a column holds are separate facts about a fragment, so writing a deletion file and rebinding a field's data both land; the legacy operation pairing had to reject this.

Not included

Merge and Project remain untranslatable from the operation alone, as do the two rewrite forms of Update, for the reason above.