*: Pare down usage of buf linting

[ParkMyCar]

This PR pares down our usage of the buf protobuf linting tool by marking most of the files as ignored. There are relatively few files we actually need to maintain backward compatibility for, most are used for communication between environmentd and clusterd which are guaranteed to be running the same version of Materialize.

Concretely, this changes bin/lint to require protobuf files to be marked with buf breaking: (ignore | check) and updates all of the files not currently marked.

Motivation

buf linting has tripped us up before by requiring backwards compatibility where it's not needed. See this Slack thread.

Tips for reviewer

What really needs review here are that the protobuf files are correctly marked ignore or check

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.

[jkosh44]

For the repr modules, how did you determine which one were written down and which weren't?

[ParkMyCar]

Checked where the messages were used, they were generally used in the errors returned from functions (not durably persisted) or in the ProtoRow encoding (durably persisted). More than happy to just mark everything in repr as check if you think that's better

[jkosh44]

IMO, marking the whole crate as check feels much safer to me unless there's an obvious and quick way to validate that some file is or isn't persisted.

[antiguru]

Not strongly opposed, but past experience tells me this eventually will break someone's code. I've seen incidents in the past where something silently started writing down a proto that wasn't considered to have stability requirements, but through a long dependency chain still was serialized. Ideally, we have a lint that checks all protos ever recorded durably only depend on protos with backwards compatibility, but I'm not sure that exists.

Otoh, this doesn't move us to a much worse place than we're currently in, and we'll need to revisit all of our proto infrastructure if we start storing protos durably outside persist.

[ParkMyCar]

not necessary any more