[txn-wal] Remove a long-unused config and operator

[bkirwi]

This flag has been enabled in prod and staging for over a year. At this point it seems unlikely that we go back to the resource-intensive and now-untested impl.

IIUC this flag was also a bit risky: since we use the flag to determine which operator to use, if config synced differently to different nodes, we might render different operators in different workers and cause some real weird timely bugs.

Motivation

txn-wal is a bit underowned at the moment, so it seems worthwhile to clean out the bits that we're not using.

[teskje]

🎉

[teskje]

IIUC this flag was also a bit risky: since we use the flag to determine which operator to use, if config synced differently to different nodes, we might render different operators in different workers and cause some real weird timely bugs.

Fwiw, this shouldn't be an issue because updates to ComputeState::worker_config are serialized with CreateDataflow commands in the compute protocol. If you know of a way how this might still go wrong, I'd be very interested to know about it! There are other feature flags that also affect dataflow rendering and rely on this working correctly.

[DAlperin]

I <3 deleting code

[bkirwi]

If you know of a way how this might still go wrong, I'd be very interested to know about it!

I suppose if all the writes to the config reliably happen-before the reads on all workers, then things are probably fine! (Hopefully storage's mechanism is similarly robust here.) I've recently squashed a handful of bugs on the Persist side where poorly timed config updates could cause things to get out of sync, so I'm a bit extra sensitive to this class of risk...