orchestratord test: rolling upgrade + introduce mz-debug

[def-]

Shouldn't be set, as noted by @alex-hunt-materialize
Test run: https://buildkite.com/materialize/nightly/builds/14124

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]

Suggested change

	or status["conditions"][0]["type"] != "UpToDate"
	or status["conditions"][0]["type"] != "UpToDate"
	or status["conditions"][0]["status"] != "True"

The UpToDate condition can have one of three statuses:

• "True"
• "False"
• "Unknown"

Typically, when we make changes to the materialize CR, but don't request a rollout, it changes to "False". When we request a rollout, it changes to "Unknown". When it completes the rollout and nothing has changed in the configuration, it changes to "True".

We still need to check the lastCompletedRolloutRequest in the "True" case, to ensure that the "True" value isn't there from a previous rollout and orchestratord has reconciled the Materialize CR since the last change.