orchestratord test: Introduce workflow for downtime measurement

[def-]

Fixes: https://github.com/MaterializeInc/database-issues/issues/9929

Only look at the last commit since this is based on #34214 to prevent conflicts

Test run: https://buildkite.com/materialize/nightly/builds/14211#019abc85-77bd-4296-a719-137a07f3f221

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.

[def-]

@jubrad Does this make sense as the way to measure downtime? I'm counting the time to run kubectl port-forward, create a new SQL connection and run a query. It's all pretty fast since it's local anyway. https://github.com/MaterializeInc/materialize/pull/34286/files#diff-0ef29e4d4b1771d6d4b7d91d28b9e9cf9b2d0cb37fef898377dbc3792aff9ab9R1526

Edit: The initial connection took 2.2 s, after the 0dt upgrade 9.6 s. This is with no objects created at all.