Remove the FoundationDB consensus and timestamp oracle backends

[antiguru]

FoundationDB was wired in behind a foundationdb cargo feature as an alternative persist consensus and timestamp oracle backend, with a supporting mz-foundationdb crate, an mzcompose server image, CI jobs, and a libfdb_c.so copy in all three production base images.

Nothing depends on it, and linking the FoundationDB C client into testdrive, environmentd and clusterd carries a teardown hazard: the contract in mz-foundationdb requires dropping every Database and transaction handle and then calling shutdown_network() before exit, but the NetworkAutoStop guard lived in a static that Rust never drops, so fdb_stop_network never ran and the C network thread outlived Rust teardown. That surfaced as glibc heap corruption aborting testdrive at process exit.

Removing the backends drops the hazard along with the maintenance cost of the client pin, which was coupled across three Dockerfiles, a Homebrew cross-compilation formula, and the crate's API feature.

Description

Deleted: the mz-foundationdb crate, FdbConsensus, FdbTimestampOracle, the test/foundationdb composition and server image, the mzcompose FoundationDB service, doc/developer/foundationdb.md, and the -foundationdb dependency-lint ground truth files.

Unwired: the foundationdb feature from persist, persist-client, timestamp-oracle, adapter, clusterd, environmentd, materialized and testdrive; the workspace member and the foundationdb workspace dependency; the ConsensusConfig::FoundationDB and TimestampOracleConfig::Fdb variants and their URL schemes; the libfdb_c.so COPY from the three prod base images; the client .deb from the CI builder; the libfdb-c-* Homebrew formula from xcompile.py; the nightly testdrive-fdb and fdb pipeline steps; the FDB service and cluster-file plumbing in the cargo-test composition; bin/run --foundationdb; and the nextest retry overrides for the FDB unit tests.

futures-util is dropped from mz-timestamp-oracle along with its unused-deps ignore, since only the FDB oracle used it. Cargo.lock loses only the foundationdb* crates and their exclusive transitive dependencies, with no version changes elsewhere.

doc/developer/design/20220404_metadata_storage.md still mentions FoundationDB as an option weighed at the time; it is left as the historical record it is.

Verification

cargo check --workspace, bin/fmt --check and bin/lint-cargo pass. No tests were added or modified; the FDB-specific unit tests are removed with the code they covered.

Closes: PER-82

🤖 Generated with Claude Code

https://claude.ai/code/session_01ETNBVh4CrGA53FJTNS9m4v

---

Generated by Claude Code

[linear-code]

PER-82

[antiguru]

buildkite/test/checks-parallel-2 failed (build 133929). I can't read the job log from my environment (no Buildkite CLI, MCP, or dashboard token), so I have not identified the error itself, and I have no means to re-run the job.

Evidence that it is not this PR's:

• That job is checks-no-restart-no-upgrade, which runs with --no-external-metadata-store. Every line this PR removed from materialized.py sits inside if external_metadata_store:, so it is not on that job's path.
• Dumping Materialized(...).config and Testdrive(...).config from this branch and from origin/main, for external_metadata_store in False/True/"toxiproxy", gives byte-identical output modulo the tree path. The generated composition does not change.
• The rebuilt materialized image is healthy on this commit: mysql-rtr and postgres-rtr use the same image and passed, which rules out the one runtime-visible change here (dropping libfdb_c.so and the foundationdb feature from the image).
• The job runs --execution-mode=parallel with --seed=$BUILDKITE_JOB_ID, so it is randomized per run.

No fix exists to port. Someone with Buildkite access should check the annotation; if it names a real regression I'll take it.

---

Generated by Claude Code

[ggevay]

(slack thread)

[antiguru]

Read the annotation now that I have Buildkite access. The failure is SS-415, open and labelled Test Blocker:

thread 'timely:work-0' panicked at src/storage/src/storage_state.rs:1084:30:
only alter compatible exports permitted: AlterError { id: User(23) }

That panic killed materialized, so the coordinator and catalog consistency checks then failed with DNS errors against a dead container. Those are the cascade, not the cause.

SS-415's own description already lists build 133929 among its occurrences, alongside five other unrelated branches in the past week. The panic is in src/storage, which this PR does not touch, and the job passed on its last five main runs.

Retried the job once: Checks parallel 2.

---

Generated by Claude Code

[antiguru]

Thanks for the reviews!