Simplified rollout triggers and CRD design doc

[alex-hunt-materialize]

Simplified rollout triggers and CRD design doc

Motivation

• This PR adds a known-desirable feature.
  Part of https://linear.app/materializeinc/issue/DEP-7/design-simplifying-upgrade-rollouts-node-rolls-converted-to-project

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.

[doy-materialize]

the service account annotations and labels are also applied immediately, so they probably shouldn't be here (although a change to serviceAccountName will require a rollout since that needs to update the corresponding field on the statefulset)

[alex-hunt-materialize]

I think they might still be load bearing, despite being applied immediately. If we change the annotations on the service account to add an AWS IAM role ARN for example, do the credentials get applied to existing pods? I'm not sure if they do.

[doy-materialize]

ah, i guess that's true. may be worth testing to see what the behavior here is, but i think you're probably right. we'll probably want to leave a comment explaining this, since it's not immediately obvious

[alex-hunt-materialize]

I've added a comment.