chore: add channel consensus state rpc

[DimitrisJim]

Description

Note, we don't have a cli for this in main so didn't add one here. Can add it if needed (assume it doesn't exist in main for a reason)

closes: #XXXX

---

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 the 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 and Go style guide.
• Wrote unit and integration tests.
• Updated relevant documentation (docs/).
• Added relevant godoc comments.
• Provide a conventional commit message to follow the repository standards.
• Include a descriptive changelog entry when appropriate. This may be left to the discretion of the PR reviewers. (e.g. chores should be omitted from changelog)
• Re-reviewed Files changed in the GitHub PR explorer.
• Review SonarCloud Report in the comment section below once CI passes.

[AdityaSripal]

Maybe a stupid question since all queries seem to have this. But why have proof in the response if it is always nil? I understand proof is not retreivable from within the state machine. Will it be filled through a different gateway?

[damiannolan]

Agree we normally put it in our msgs because we offered some CLIs which short-circuited grpc by hitting abci directly - in those cases we fulfil proof and proofHeight. But if we don't offer that kind of CLI here then don't see the point in putting it in the proto msg. You can still query abci directly and get a proof back for it.

One thing to consider is that other consumers of the protobuf messages treat them as canonical apis for different runtime envs (e.g. penumbra etc)... not sure how that affects decision making here tho..

[DimitrisJim]

One thing to consider is that other consumers of the protobuf messages treat them as canonical apis for different runtime envs (e.g. penumbra etc)... not sure how that affects decision making here tho..

think this is good enough justification for now to keep things as is for time being (and as we historically did). Maybe its a point to be raised with other teams/consumers of proto defs though and possibly rm'ing them after that is resolved.

[sonarqubecloud]

Quality Gate passed for 'ibc-go'

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud