storage: make suspend and restart delay configurable, drop to 5s from 30s

[pH14]

#26139 + https://github.com/MaterializeInc/cloud/issues/8965 have the full context, but the tl;dr is that sources can take a long time reconnect after momentary network blips. This means <1s of network downtime can turn into >60s of actual source/sink unavailability. One of the primary sources of downtime is the fixed 30s SUSPEND_AND_RESTART_DELAY.

This PR makes two small changes to this knob:

1. Makes it configurable
2. Drops the default to 5s, down from 30s

A more advanced solution would be using exponential backoff, but it's not quite clear to me how to make that work within the healthcheck operator. Tossing this up as a proposal, and will let a member of @MaterializeInc/storage determine whether it's sufficient 😄

Motivation

In part addresses #26139, though it'd be nice to move to exponential backoff eventually.

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).
• This PR includes the following user-facing behavior changes:

[guswynn]

Doing backoff IS quite a bit more annoying, you are right! I am personally fine with this, will get sign off with rest of the team

[guswynn]

@pH14 looks good!

The ci failure is because that test is checking against mz_sink_statuses, which cycles through running and stalled; instead it should check that mz_sink_status_history has stalled in its history