Replace /abci_info RPC call with either /status or /abci_query gRPC call

[seanchen1991]

Summary

Problem Definition

The query_application_status function currently needs to perform two separate status queries in order to obtain the latest info regarding application status. More specifically:

1. It calls into the /abci_info RPC endpoint that Comet exposes in order to obtain the latest height h that the application executed.
   

   hermes/crates/relayer/src/chain/cosmos.rs

   Lines 946 to 948 in daad028

   	let abci_info = self
   	.block_on(self.rpc_client.abci_info())
   	.map_err(|e| Error::rpc(self.config.rpc_addr.clone(), e))?;

2. It then calls into the /blockchain?minHeight={h}&maxHeight={h} RPC endpoint, also exposed by Comet, in order to extract the timestamp from the header of the block at height h.
   

   hermes/crates/relayer/src/chain/cosmos.rs

   Lines 954 to 960 in daad028

   	let blocks = self
   	.block_on(
   	self.rpc_client
   	.blockchain(abci_info.last_block_height, abci_info.last_block_height),
   	)
   	.map_err(|e| Error::rpc(self.config.rpc_addr.clone(), e))?
   	.block_metas;

This logic should ideally changed to utilize either the /status gRPC endpoint or the /abci_query gRPC endpoint.

The /status endpoint currently does not provide the metatdata that we need, though it will make sense to switch to it if it is changed to match the requirements listed in this comment.

The /abci_query endpoint also cannot currently be used in its current form, as it does not offer support for proofs.

Acceptance Criteria

• Change the query_application_status function to utilize either the /status or /abci_query gRPC endpoint when one becomes appropriate for our use case.

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate milestone (priority) applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned