add height field to gRPC requests

[noot]

Description

Adds height field to relevant gRPC requests and latest_height bool to override height and query at the latest height.

Following up to my previous PR #5685 - this came up as an issue again when testing IBC with the hermes relayer, as only proofs at the latest height were returned, but this is not the state root we were expecting to compare against, causing verification errors.

Let me know any thoughts/feedback on this approach, if it looks good I can update the rest of the code.

closes: #149

---

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.

[damiannolan]

Hi @noot, thanks for opening the PR. I have a couple of questions:

• How would these fields intend to be used inside of the ibc-go implementation code?
• Are you using a different implementation of ibc where you are seeing the errors mentioned?

this came up as an issue again when testing IBC with the hermes relayer, as only proofs at the latest height were returned, but this is not the state root we were expecting to compare against, causing verification errors.

I think I mentioned in the previous PR that the intended approach for querying state at historical heights is to the x-cosmos-block-height. It is up to the implementation of the application to consume this correctly, and load a version of the db store at the given height within this header.

[noot]

Hi @damiannolan ,

Are you using a different implementation of ibc where you are seeing the errors mentioned?

yes, I'm using the Rust IBC implementation by penumbra and a fork of the hermes relayer which uses the gRPC API to query for IBC state and respective proofs.

How would these fields intend to be used inside of the ibc-go implementation code?

The IBC implementation would return proofs at the specified heights for those queries. Right now, the server always returns the proofs at the latest height as no height can be specified (see here) which sometimes causes off-by-one errors, as hermes expects a block at some height, but the latest height has already advanced.

the intended approach for querying state at historical heights is to the x-cosmos-block-height

This is the workaround I'm currently doing, however I'm not using cosmos so using a cosmos-specific approach seems off. I think having the heights in the requests would be preferred for non-cosmos IBC implementations, but if putting the height in the gRPC header is the accepted method, that is also ok.