[storage] Minor controller cleanups and refactoring

[bkirwi]

Some minor drive-by as I've been reading through the storage controller.

Motivation

The first commit is inspired by a recent incident: we saw a bunch of Persist memory on the stack of an environment, some of which was allocated by this warmup code. Far from a smoking gun... but in general it feels wise to not attempt unbounded concurrent work, especially for an optimization like this one.

The others are hopefully self-explanatory, but let me know if anything seems odd!

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.

[ParkMyCar]

All makes sense to me!

My only hesitation is the removal of status_id from the SinkDesc because I'm not sure if we intend to use it in the future. Worse case though it can always be re-added!

[bkirwi]

My only hesitation is the removal of status_id from the SinkDesc because I'm not sure if we intend to use it in the future.

Thankfully this one I'm pretty confident about, since it dates back to when I was following this stuff more closely. 😅 Sinks originally wrote their own status updates to the status collection, but those writes got moved to the controller... I believe this just never got cleaned up.