Rollout strategy enum

[alex-hunt-materialize]

Deprecates and ignores the inPlaceRollout field of the Materialize CR, instead replacing it with a new rolloutStrategy enum field.

The enum has two variants: WaitForRollout (the default) and ImmediatelyPromoteCausingDowntime. Hopefully these new names will be more clear.

We increment the the generation in both variants, so we avoid the weird behavior we saw with inPlaceRollout previously. Both variants follow almost the same code path, with the exceptions of ImmediatelyPromoteCausingDowntime doing as its name implies, deleting the old generation first and immediately promoting the new generation.

Motivation

• This PR fixes a previously unreported bug.
  Several customers have accidentally used inPlaceRollout, when they should not have. Even internally, this field is confusing, and it has lots of strange behavior caused by not incrementing the generation.

Tips for reviewer

It's easier to review each commit individually.

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.

[alex-hunt-materialize]

@def- I've manually tested upgrades for both variants, and I've run the nightly orchestratord tests. Is there anything else we need for this? We probably want to add this to the upgrade tests once those are ready, but I don't think that should block this PR.

[def-]

The terraform upgrade test, but that is currently WIP in another PR. So all good from QA side.

[doy-materialize]

overall looks fine, other than the one minor issue

[doy-materialize]

you can use derive(Default) and the #[default] variant annotation instead of deriving this by hand