Populate x/consensus Params grpc query's AppVersion field

[amaury1093]

Summary of Bug

Part of #13902

In x/consensus's Params field, the the response.VersionParams.app version field is never set.

Description

Tendermint's consensus params look like this:

message ConsensusParams {
  BlockParams     block     = 1;
  EvidenceParams  evidence  = 2;
  ValidatorParams validator = 3;
  VersionParams   version   = 4;
}

Since v0.47, the three first fields are stored in x/consensus state. However, the 4th field (AppVersion) is stored in x/upgrade, because it shouldn't be modifiable by gov proposals, only bumped on coordinated upgrades.

The bug is that when doing a x/consensus Params gRPC query, the response type includes all 4 fields, above, but the last one (AppVersion) is never populated because it's stored in another module

Proposal

Proposal 1: Keep AppVersion inside x/upgrade.

Proposal 1a: We can simply document (e.g. in the proto comments) that the AppVersion field is never populated in x/consensus, it is tracked in x/upgrade
Proposal 1b: We can let x/consensus hold a reference to (ie. depend on) x/upgrade, can retrieve that AppVersion param on gRPC call.

Proposal 2: Store AppVersion inside x/consensus.

Since we have this new module, maybe it makes sense to store all Tendermint's consensus params in one place. However, this introduces the following refactors:

• Make x/upgrade depend on x/consensus (to be able to update x/consensus's state on upgrade plan run)
• A migration

---

For v0.47 I'm proposing to go with 1a.

[tac0turtle]

1a makes sense here for 0.47.