Re: UNDO with FILEOPS, and the FLUX table AM

Hi Greg,

> so, hopefully I've delivered v7 with:

You did, and it's the real v7 this time. I ran the three checks I said I
would, on master at 964d88fac46 (there is a rebase note at the end):

test_fileops/t/017 passes on all three paths -- online ROLLBACK, abort redo on
a standby, startup undo -- 12/12, and t/018 (rename) is 68/68. FileOpsRename
is immediate-with-rollback as of 0005, which is what the harness expected. The
logical-revert-worker path that 0005 also mentions isn't exercised by 017, so
that one is still uncovered if you want to add it.

Per-prefix: all 20 prefixes build without warnings and pass the core check plus
their own tests. The three things I flagged on v4 are fixed -- test_fileops is
registered from 0002, 0004 carries only recovery/071, and recovery/134 passes
in 0006.

The fsync repro from the v6 thread, v4 vs v7, same machine, on a quiet lane
(median with bootstrap CI95, n=9; both are cassert builds, so these are
ratios, not production absolutes):

- ROLLBACK of 32,000 chmods: 23.3 s -> 49.6 ms.
- startup undo, 32,000 in flight: 24.3 s -> 48 ms.
- abort redo of 32,000 inverses (n=3): ~24.8 s -> ~0.06 s.

That is roughly 470x, 500x and 400x, and the gap grows with N (46x at 200),
which matches v4 doing one fsync per record and v7 batching them.

One rebase note: the posted v7 doesn't apply on current master (26bd08f):
0002 conflicts in recovery/meson.build with 068c9aaec31 (the new
t/060_multixact_crashed_updater.pl) and leaves a duplicate 060. It is a
context conflict; I measured on 964d88fac46, where git am is clean. cfbot will
need the rebase too.

Regards,
Manu