Switch third-party proto import and codegen to use buf tool

[JimLarson]

What is the Problem Being Solved?

In the 0.47 cosmos-sdk release, they made a number of changes in proto-handling. There is greater reliance on using the buf tool for managing proto dependencies instead of maintaining a third_party proto directory. They have taken over support of the gogoproto suite and now use their own version explicitly. There is also a custom code generator for handling the extensions in the Pulsar system for managing collections in the store.

We will inherit all of these changes in our Interchain stack dependencies. We have a choice of what we'd like to do for our own proto compilation in agoric-sdk.

• We'd like to stick close to the Interchain technology choices, and in particular we'd like to stay as close as possible to gaia as the exemplar of Cosmos applications.
• If we need proficiency with buf anyhow for dealing with the Interchain stack, we might as well benefit from using it for third-party code management, which currently involves some manual steps.
  • However, we have a bit of a conundrum with our modifications to Cosmos protos for vesting accounts. We cannot publish these in the Cosmos namespace. However, our agoric-sdk does not have a dependency on these modified protos. We use only Cosmos base definitions like coin.proto.
• If we want to start using the collections feature for our own protos, we'll want to use their codegen tool. But I don't know if their codegen supports JS or TS, or if its support works well with our JS-side expectations.

The task here is to examine the changes in 0.47 and confer with @turadg to see what's reasonable for the cosmic-proto package and friends.

Description of the Design

Security Considerations

Scaling Considerations

Test Plan

Upgrade Considerations

[JimLarson]

See also #9181