compute,storage: downgrade config update logs

[teskje]

This PR downgrades the "Applying configuration update" logs from info to debug. They have become extremely noisy over time as we have accumulated more config options, and especially with the introduction of the dyncfgs.

Motivation

• This PR fixes a recognized bug.

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

Tips for reviewer

I would prefer to either (a) log only actual config changes or (b) send only actual config changes from envd to clusterd. But I didn't find a good way to implement (a) with our current {Compute,Storage}Parameters definition and (b) requires a refactor of adapter code I'm not very familiar with.

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.

[petrosagg]

Thank you! It was about time

[antiguru]

I agree with the sentiment, but just last week this was crucial to me to debug an issue. I think we should do something else here: only print the configuration that has changed. (This was to understand 0dt behavior, so we couldn't even apply a new debug level without restarting envd.)