FM-34: Query

[aakoshh]

Closes consensus-shipyard/ipc#347

The PR implements a QueryInterpreter and the mappings to ABCI request and results. It builds on #37 which already split the fvm interpreter into smaller parts.

I implemented two queries based on the hints in the docstrings of the abci::request::Query type:

• one directly over the IPLD block store
• one over the state tree

In the future we can expand the range of queries with more specialized ones that work on specific built-in or IPC actors. For example we could have a special query to get values from the FEVM store, or return epoch based things from the ledger. That said, it is already possible for a client to use the above two queries to 1) get the state of an actor which has the state root hash and 2) pull the CBOR corresponding to that state and 3) parse it into the right data structures.

Still, it would introduce less coupling between clients and actors if the data is interpreted on the node. We'll see.

Another type of query we can add, which would also add another layer to the queries, is a ChainQuery type, which would either be over the FVM (ie. wrap the current type), or be over the state of the CIDs proposed for resolution, e.g. it could ask if a particular CID is final, if it's been resolved, etc.

Query at different points of the chain

The request has a height field which I am not using now, I'm always returning the latest data. As noted in the ticket, this is not the best solution because it's impossible to know if two queries run one after the other are consistent with each other. I created a follow up ticket to extend the application state: consensus-shipyard/ipc#346

Query over pending state

Etheremint takes transactions in the mempool into account: https://docs.ethermint.zone/core/pending_state.html

I didn't implement this.