feat(evm): add query for confirmation height

[jack0son]

Description

Adds a query to get the confirmation height for a given chain to allow the microservices' deposit confirmation process to validate deposits.

Once #1240 is included in the next upgrade, this information can be read from the vote result instead.

Todos

• Unit tests
• Manual tests
• Documentation
• Connect epics/issues
• Tag type of change

Steps to Test

Expected Behaviour

Other Notes

[fish-sammy]

Can't this be done already by querying axelard q params subspace?

[jack0son]

Can't this be done already by querying axelard q params subspace?

What would the exact query for the ethereum confirmation height look like?

Can we include this PR for now so the microservice calling this can use its existing EVM module client?

[jcs47]

Please don't use the legacy querier. Move this to the newly created grpc query service.

[jcs47]

What would the exact query for the ethereum confirmation height look like?

with grpcurl:

joaosousa@MBP-de-Joao axelarate % grpcurl -plaintext -d '{"subspace":"evm_ethereum", "key":"confirmationHeight"}' localhost:9090 cosmos.params.v1beta1.Query/Params 
{
  "param": {
    "subspace": "evm_ethereum",
    "key": "confirmationHeight",
    "value": "\"1\""
  }
}

AFAIK, grpcurl is also available as a go library. Is it too much of a hassle to incorporate it into the ms and use that instead to retrieve the confirmation height? Also, bear in mind that the "subspace" parameter must be all lower case for the query to work.

[jcs47]

Can't this be done already by querying axelard q params subspace?

We can fetch the same piece of information using that query instead. But I think there might be an advantage on adding this query to the evm module, in the sense that nobody would need to dig into the code and figure out the names that are used for the subspace and key -- specially if it is a piece of information that is gonna get retrieved frequently, which I think it will be (not just by our own micro-service, but other hypothetical third-party applications).

[jack0son]

Can't this be done already by querying axelard q params subspace?

We can fetch the same piece of information using that query instead. But I think there might be an advantage on adding this query to the evm module, in the sense that nobody would need to dig into the code and figure out the names that are used for the subspace and key -- specially if it is a piece of information that is gonna get retrieved frequently, which I think it will be (not just by our own micro-service, but other hypothetical third-party applications).

Second this. The added query is more robust because it requires less knowledge on the client side.