ChainEndpoint queries' IncludeProof refactor

[plafer]

Preemptively approved, thanks a lot for going through this @plafer!

It's a bit unfortunate that we now cannot statically rely on the proof being present in the returned type when IncludeProof is Yes but we can perhaps find a way to recover this statically in a follow-up PR, perhaps with something like:

trait WithProof<Proof> {
    type Proof;

    fn include_proof(&self) -> bool;

    fn build_proof<E>(&self, build: impl FnOnce() -> Result<Proof, E>) -> Result<Self::Proof, E>;
}

struct IncludeProof;
struct NoProof;

impl<Proof> WithProof<Proof> for IncludeProof {
    type Proof = Proof;

    fn include_proof(&self) -> bool { true }

    fn build_proof<E>(&self, build: impl FnOnce() -> Result<Proof, E>) -> Result<Self::Proof, E> {
        build()
    }
}


impl<Proof> WithProof<Proof> for NoProof {
      type Proof = ();

      fn include_proof(&self) -> bool { false }

      fn build_proof<E>(&self, _build: impl FnOnce() -> Result<Proof, E>) -> Result<Self::Proof, E> {
          Ok(())
      }
}

impl ChainEndpoint for CosmosSdkChain {
   fn query_channel<P: WithProof<MerkleProof>>(
         &self,
         request: QueryChannelRequest,
         with_proof: P,
     ) -> Result<(ChannelEnd, P::Proof), Error> {
       // ...

         let res = self.query(
             ChannelEndsPath(request.port_id, request.channel_id),
             request.height,
             with_proof.include_proof(),
         )?;

         let channel_end = ChannelEnd::decode_vec(&res.value).map_err(Error::decode)?;

         let proof = with_proof.build_proof(|| res.proof.ok_or_else(Error::empty_response_proof))?;

        Ok(channel_end, proof)
     }
}

Not clear how that would interact with the chain runtime, but we might be able to solve this in one go once we move the queries out of the runtime and expose them directly from the ChainHandle.

@plafer @soareschen What do you think?

Rust playground

Originally posted by @romac in #2226 (review)