adapter: prep only once in peek/copy_to optimization

[ggevay]

Prepping in two phases made sense before #33533 (where phase 1 is with EvalTime::Deferred), because meaningful things were happening between the two phases, which were benefitting from phase 1 doing at least partial prepping. But after phase 2 was moved earlier in that PR, now the two phases are very close to each other, and the code between them is not sensitive to phase 1's existence. So, this commit just removes phase 1, and then also removes the now-unused EvalTime::Deferred.

[github-actions]

Thanks for opening this PR! Here are a few tips to help make the review process smooth for everyone.

PR title guidelines

• Use imperative mood: "Fix X" not "Fixed X" or "Fixes X"
• Be specific: "Fix panic in catalog sync when controller restarts" not "Fix bug" or "Update catalog code"
• Prefix with area if helpful: compute: , storage: , adapter: , sql:

Pre-merge checklist

• The PR title is descriptive and will make sense in the git log.
• This PR has adequate test coverage / QA involvement has been duly considered. (trigger-ci for additional test/nightly runs)
• If this PR includes major user-facing behavior changes, I have pinged the relevant PM to schedule a changelog post.
• 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).

[mgree]

LGTM!

Something I don't understand---likely a problem with my understanding of unmaterializable functions---is why we #33533 only applied to COPY TO and SELECT but not the read-then-write plans for INSERT, UPDATE, or DELETE. But even with that lack of understanding, I agree that we no longer need to do the expr prep twice.

[ggevay]

Thanks for the review!

#33533 does apply to read-then-write plans, in that sequence_read_then_write calls sequence_peek, which calls the peek optimizer, where #33533 and the current PR made changes. Does this answer the question?

[mgree]

Ah, yes---that makes sense. I saw peek.rs and overfit.