Lighten some catalog references

[ggevay]

We had a bunch of places with a &mut Catalog or an Arc<Catalog> where a simple &Catalog is enough. &Catalog is better performance-wise, because creating a &mut Catalog by calling catalog_mut clones the whole catalog if there are any other Arcs to it at that moment.

(Regarding the catalog_mut calls whose return value is used in an allocate_user_id or similar call, 169b1a1 made allocate_user_id not take a &mut, which made it possible to do the change in the current PR.)

Nightly Feature Benchmark: https://buildkite.com/materialize/nightly/builds/13862

Motivation

• This PR refactors existing code.

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).
• If this PR includes major user-facing behavior changes, I have pinged the relevant PM to schedule a changelog post.