Frontend peek sequencing -- graceful handling of dependency drops for slow-path peeks and COPY TO

[ggevay]

In my earlier slow-path peek and COPY TO PRs I conveniently forgot about the dependencies dropping during sequencing problem. Nightly now reminded me of this with some dataflow creation cannot fail panics.

This PR makes us gracefully handle this problem, with showing AdapterError::ConcurrentDependencyDrop to the user.

Nightly (subset): https://buildkite.com/materialize/nightly/builds/14259

(Temporarily turns on enable_frontend_peek_sequencing in CI. I'll remove this commit before merging.)

[ggevay]

This change can possibly affect the old peek sequencing, but I hope that's ok.

[def-]

I think this fixes the issue we just saw in Nightly on main?
parallel-workload-materialized-1 | thread 'coordinator' panicked at src/adapter/src/util.rs:262:23: cannot fail to create dataflows: SinceViolation(User(340))
Seen in Parallel Workload (rename)

[ggevay]

Hmm, it doesn't fix SinceViolation. Specifically for SinceViolation, it makes that from a panic into an InternalError, but that's still not good. I'll look into this more.

[teskje]

LGTM

[ggevay]

I'll merge this now, because it should improve the situation, but the SinceViolation is still a mystery. I'll investigate that more. It happened in a slow-path peek's create_dataflow's validation, and I don't understand how:

• The read_holds variable in try_frontend_peek_inner is alive until the end of try_frontend_peek_inner.
• ExecuteSlowPathPeek doesn't return before implement_peek_plan calls create_dataflow.

(I've checked that Parallel Workload has an ignore for ConcurrentDependencyDrop's error msg, but not for the internal error. So, some of the Nightly failures will go away after merging this, but not those that are due to SinceViolation.)