Support Height Queries

[alexanderbez]

Summary

Height-based queries are currently disabled (removed completely) from the client interfaces. There are two notable reasons for initially doing so:

1. Nodes, by default, have pruning enabled.
2. Most, if not all, querying is now done through the concept of Queriers which do not necessarily directly query the store.

With regards to (1), if the node has pruning enabled, we need to make sure any height query fails gracefully.

With regards to (2), the general flow is some sort of query params are constructed and serialized. These serialized params are then sent to CLIContext#QueryWithData, which underneath constructs a ABCIQueryOptions and calls ABCIQueryWithOptions. Via ABCI this gets routed to the BaseApp's Query method, namely under the custom switch case which further calls handleQueryCustom. Here in handleQueryCustom is where I believe we would need to utilize the height and try to load it returning an error upon failure (it's currently not being used at all).

/cc @ebuchman @cwgoes @jackzampolin

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned

[jackzampolin]

This is needed for better reporting for validators. I spoke with Matt Harrop from Figment and he thought the two queries that are in most need of height support are:

• Account balance at height
• Unclaimed rewards/commission at a block height