Audit / Refactor proto packages layout

[clevinson]

Description

New proposed layout:

• Follow buf's best practices and add package version suffix everywhere
• Current version is v1beta1, and every package has this version

.
├── cosmos
│   ├── bank
│   │   └── v1beta1
│   │       ├── bank.proto
│   │       ├── genesis.proto
│   │       ├── query.proto
│   │       └── tx.proto
│   ├── base
│   │   ├── abci
│   │   │   └── v1beta1
│   │   │        └── abci.proto
│   │   ├── crypto
│   │   │   └── v1beta1
│   │   │       └── crypto.proto
│   │   ├── store
│   │   │   └── v1beta1
│   │   │       └── kv.proto
│   │   ├── query
│   │   │   └── v1beta1
│   │   │       └── pagination.proto
│   │   └── v1beta1
│   │       └── coin.proto
│   └── tx
│       └── v1beta1
│           └── tx.proto

Highlights of the main changes made:

1. cosmos/cosmos.proto refactored to cosmos.base
   a. ValidatorAddresses moved to cosmos.staking
   b. cosmos.base left with 2 files:
   1. cosmos/base/abci.proto, containing all proto definitions related to simulation / broadcast / responses from tendermint (e.g. Result, GasInfo, TxResponse...)
   2. cosmos/base/coin.proto, containing coin related proto definitions
      c. all remaining non-module packages (kv, query, tx) moved under cosmos.base
2. base packages marked as stable (v1), and module packages all marked as beta (this was discussed July 31st's architecture call, notes here)
3. cosmos module Msg's moved into a tx.proto file within each module package (as proposed by @amaurymartiny when commenting on Audit Protobuf package names & update RegisterInterface calls #6822)

closes: #6822

---

Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.

• Targeted PR against correct branch (see CONTRIBUTING.md)
• Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
• Code follows the module structure standards.
• Wrote unit and integration tests
• Updated relevant documentation (docs/) or specification (x/<module>/spec/)
• Added relevant godoc comments.
• Added a relevant changelog entry to the Unreleased section in CHANGELOG.md
• Re-reviewed Files changed in the Github PR explorer
• Review Codecov Report in the comment section below once CI passes

[clevinson]

Some notes on the various messages that I'd still like to be pulled out of cosmos.base:

My initial thought was to pile everything inside packages within cosmos.tx, but there's a few reasons why that may not be the best solution...

• SimulationResponse, Result, GasInfo
  • Could be cosmos.tx.simulation, but there are uses in go files of Result & GasInfo that dont necessarily correspond to a SimulationResponse (e.g. types/result.go)...
• MsgData and TxData
  • Seems most related to the cosmos.tx package?
• TxResponse, ABCIMessageLog, etc.
  • Could put them in a new cosmos.tx.broadcast package as these are mostly used in broadcast, but there are other places where `ABCIMessageLog is used directly from the proto definition, so perhaps needs broader contextual home?

[codecov]

Codecov Report

Merging #6905 into master will increase coverage by 3.49%.
The diff coverage is 55.55%.

@@            Coverage Diff             @@
##           master    #6905      +/-   ##
==========================================
+ Coverage   61.86%   65.36%   +3.49%     
==========================================
  Files         520      390     -130     
  Lines       32108    24271    -7837     
==========================================
- Hits        19865    15864    -4001     
+ Misses      10628     7165    -3463     
+ Partials     1615     1242     -373     

[clevinson]

Please see updated description above, which gives an overview of the changes being made in this PR.

The piece I'm least certain about is the beta naming of all module packages (basically every proto package that corresponds to an "sdk module that lives in x/"). It was discussed in the architecture call today (notes here) that there really isn't anything that we can confidently say won't change in the future, except maybe that in cosmos.base.

Not sure if thats 100% the best way to structure stuff, but this is my attempt at it. Also- i'll be on vacation next week and am happy for anyone else to pick this up while i'm out and push it over the finish line.

[aaronc]

Why beta and not the more standard v1beta?

I think cosmos and cosmos.tx should both be beta as well, at least cosmos.tx

[aaronc]

I've thought about this a bit more. My biggest hesitancy about putting everything into beta is that then we need to move everything out of beta soon which will break things.

At the same time, I also feel that calling everything stable and fixed right away does tie our hands a bit and might be a bit rushed. We're doing the first SDK protobuf release ever and there are a lot of proto definitions. We might have gotten some major things wrong or just find out a radically better way to do certain things 1-2 months after the release. So maintaining the optionality of beta status does seem merited.

What if we:

1. do our best to tag things we know are alpha/beta/etc. as proposed above
2. announce clearly that we will enforce buf break check starting with the next 0.41 release (which should have a cool name of its own - maybe "Horizon")

This reduces the churn of marking and then unmarking everything as beta but relieves the pressure of having to make all the 1.0 time decisions right now, already late for a release.

What do people think?

[aaronc]

So it seems like we agreed in the meeting today to move everything into v1beta1 packages and just communicate to early adopters that types will be moved into stable packages in future releases.

This appears to be preferred over my proposal to just delay making stable packages actually "stable".

[amaury1093]

This PR is ready for another round of review. I has been updated to reflect last Friday's call decision, see also 1st comment for an overview of the folder arch.

[clevinson]

@amaurymartiny Left a few comments, otherwise LGTM. I cannot approve / request changes, as i was the original author.

[clevinson]

We should probably still register this as a specific version (e.g. cosmos.v1beta1.Msg), right? Only thing is, since it's not actually tied to a specific protobuf definition, it's not super clear when we would update the version in the interface registry.

[amaury1093]

Good point, I changed to "cosmos.v1beta1.Msg" for now, since everything is in beta. But yeah, I guess we should also define which interfaces are beta/stable, maybe add a line somewhere in #6954?