[poc] CREATE MATERIALIZED VIEW ... REPLACING

[teskje]

I hacked together a poc exploring the implementation effort of modeling replacement MVs as materialized views, instead of a separate "replacement" item type. The benefit would be to keep the SQL surface small.

This is very hacky, but show the general idea. We use the storage controller's existing capability to specify multiple collections backed by the same shard through a "primary" relationship. This lets us create a second read-only MV that points at the same shard as the existing MV. Both MVs can co-exist, you can select from both of them, and dropping the replacement works.

There is also still some strangeness. Because I've not defined a SQL-level dependency, you can drop the "leader" MV without dropping the replacement. The strange part is that the replacement's frontier keeps advancing even though it is in read-only mode (and no updates are flowing through from the source either). What is advancing the frontier??

Also, I haven't implemented the "apply" step. Assumption is that it won't be harder to implement than in the "replacement" item type version, but that might be wrong.

Motivation

Tips for reviewer

Checklist

• This PR has adequate test coverage / QA involvement has been duly considered. (trigger-ci for additional test/nightly runs)
• This PR has an associated up-to-date design doc, is a design doc (template), or is sufficiently small to not require a design.
• If this PR evolves an existing $T ⇔ Proto$T mapping (possibly in a backwards-incompatible way), then it is tagged with a T-proto label.
• If this PR will require changes to cloud orchestration or tests, there is a companion cloud PR to account for those changes that is tagged with the release-blocker label (example).
• If this PR includes major user-facing behavior changes, I have pinged the relevant PM to schedule a changelog post.