adapter: move a replacement's expression cache entries to its target on apply

[ggevay]

This is on top of #38677, so please review the "adapter: record the item version in expression cache entries" commit there.

Motivation

#38677 fixes SQL-683 by having ExpressionCache::open drop entries recorded for an earlier definition of an item. After an ALTER MATERIALIZED VIEW ... APPLY REPLACEMENT that leaves the next boot re-optimizing the replaced materialized view once, and nothing in the logs says why an entry was dropped. This PR is stacked on #38677 (its first commit); review the second commit.

Description

After a successful apply, the coordinator asks the cache to move the replacement's own entries to the surviving item: the local entry moves under the item's root id, the global entry stays under the writing id, both are recorded at the new version, and the item's other entries are removed. The moved entries keep the optimizer features that produced them, so a feature change between the replacement's creation and the apply makes the next boot re-optimize the view like any other item. Correctness does not rest on this write, the version check in #38677 does that; it only spares the boot after an apply one re-optimization per applied replacement.

The move runs inside the cache task (ExpressionCache::restamp), reading the replacement's entries from the durable cache's local mirror. An entry that is unreadable, or missing from this process's view of the cache, is skipped and removed, leaving the next open to re-optimize what it would have served. The read and the rewrite are not atomic against another process of the same build version, which is safe because ids are never reused: whatever such a process writes under the replacement's id describes the definition being adopted.

ExpressionCache::open now logs how many entries it kept and how many it removed, by reason (dropped item, item version mismatch, dropped index import, unreadable, prior build version), so a cache miss can be attributed after the fact. An entry the running build cannot read is dropped instead of being reported on every boot; entries are only ever read by the build version that wrote them, so this can only affect entries the same build wrote.

Tests

• expr_cache unit test: the moved entries of an apply are returned under the target's ids at the new version, and the entries the move invalidates are gone even where the version check would have kept them.
• test_replacement_materialized_view_expression_cache_hit_after_apply (environmentd server tests): creates an index on the replacement's input after the replacement was planned, applies, restarts, and checks through mz_compute_dependencies that the view's dataflow still reads the input directly. A re-optimization at boot adopts the index, which is what happens without this change.

Alternatives

Writing the surviving item's in-memory plans to the cache after the apply, stamped with the cluster's current optimizer features, would avoid the re-optimization without a new cache operation. But the apply moves the replacement's plans over without re-optimizing, so a feature change between the replacement's creation and the apply would stamp an old-feature plan with the new features, and every later boot would hit and reinstall it while re-optimizing everything else on the cluster. Moving the replacement's own entries keeps the features that produced each plan.

Part of SQL-683.

---

🤖 Generated with Claude Code