chore: add into_inner() for ICS07 ConsensusState

.changelog/unreleased/improvements/1156-add-into-inner-for-ics07-consensus-state.md

@@ -0,0 +1,2 @@
+- [ibc-client-tendermint] Add `into_inner()` method to ICS07 `ConsensusState`
+  ([\#1156](https://github.com/cosmos/ibc-rs/pull/1156))

docs/architecture/adr-007-light-client-contexts.md

@@ -13,7 +13,7 @@ This ADR is meant to address the main limitation of our current light client API
     + By giving the light clients access to `ValidationContext` and `ExecutionContext`, we're effectively giving them the same capabilities as the core handlers.
     + Although our current model is that all code is trusted (including light clients we didn't write), restraining the capabilities we give to light clients at the very least eliminates a class of bugs (e.g. calling the wrong method), and serves as documentation for exactly which methods the light client needs.
 
-This ADR is all about fixing this issue; namely, to enable light clients to define their own `ValidationContext` and `ExecutionContext` traits for the host to implement. 
+This ADR is all about fixing this issue; namely, to enable light clients to define their own `ValidationContext` and `ExecutionContext` traits for the host to implement.
 
 [ADR 4]: ../architecture/adr-004-light-client-crates-extraction.md
 [later improved]: https://github.com/cosmos/ibc-rs/pull/584
@@ -26,9 +26,9 @@ This ADR is all about fixing this issue; namely, to enable light clients to defi
 
 ### Changes to `ClientState`
 
-The `ClientState` functionality is split into 3 traits: 
-+ `ClientStateCommon`, 
-+ `ClientStateValidation<ClientValidationContext>`, and 
+The `ClientState` functionality is split into 3 traits:
++ `ClientStateCommon`,
++ `ClientStateValidation<ClientValidationContext>`, and
 + `ClientStateExecution<ClientExecutionContext>`
 
 Then, `ClientState` is defined as
@@ -68,7 +68,7 @@ where
         &self,
         ctx: &ClientValidationContext,
         // ...
-    ) -> Result<(), ClientError> { 
+    ) -> Result<(), ClientError> {
         // `get_resource_Y()` accessible through `ctx`
     }
 
@@ -93,7 +93,7 @@ where `ClientExecutionContext` is defined as (simplified)
 
 ```rust
 pub trait ClientExecutionContext: Sized {
-    // ... a few associated types 
+    // ... a few associated types
 
     /// Called upon successful client creation and update
     fn store_client_state(
@@ -214,9 +214,7 @@ trait ClientState<ClientValidationContext, ClientExecutionContext>
 
 The problem with defining all methods directly under `ClientState` is that it would force users to use fully qualified notation to call any method.
 
-This arises from the fact that no method uses both generic parameters. [This playground] provides an explanatory example. Hence, our solution is to have all methods in a trait use every generic parameter of the trait to avoid this problem.
-
-[This playground]: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=da65c22f1532cecc9f92a2b7cb2d1360
+This arises from the fact that no method uses both generic parameters. Hence, our solution is to have all methods in a trait use every generic parameter of the trait to avoid this problem.
 
 ### Why did you write custom `ClientState` and `ConsensusState` derive macros? Why not use `enum_dispatch` or `enum_delegate`?
 We ended up having to write our own custom derive macros because existing crates that offer similar functionality had shortcomings that prevented us from using them:
@@ -235,7 +233,7 @@ We ended up having to write our own custom derive macros because existing crates
 
 ### Negative
 + Increased complexity.
-+ Harder to document. 
++ Harder to document.
     + Specifically, we do not write any trait bounds on the `Client{Validation, Execution}Context` generic parameters. The effective trait bounds are spread across all light client implementations that a given host uses.
 
 

ibc-clients/ics07-tendermint/src/client_state/validation.rs

@@ -232,7 +232,7 @@
         max_clock_drift: subject_max_clock_drift,
         proof_specs: subject_proof_specs,
         upgrade_path: subject_upgrade_path,
-    } = subject_client_state.clone();
+    } = subject_client_state;
 
     let substitute_client_state = ClientStateType::try_from(substitute_client_state)?;
 
@@ -249,11 +249,11 @@
         upgrade_path: substitute_upgrade_path,
     } = substitute_client_state;
 
-    (subject_trust_level == substitute_trust_level
-        && subject_unbonding_period == substitute_unbonding_period
-        && subject_max_clock_drift == substitute_max_clock_drift
-        && subject_proof_specs == substitute_proof_specs
-        && subject_upgrade_path == substitute_upgrade_path)
+    (subject_trust_level == &substitute_trust_level
+        && subject_unbonding_period == &substitute_unbonding_period
+        && subject_max_clock_drift == &substitute_max_clock_drift
+        && subject_proof_specs == &substitute_proof_specs
+        && subject_upgrade_path == &substitute_upgrade_path)
         .then_some(())
         .ok_or(ClientError::ClientRecoveryStateMismatch)
 }

ibc-clients/ics07-tendermint/src/consensus_state.rs

@@ -30,6 +30,10 @@
         &self.0
     }
 
+    pub fn into_inner(self) -> ConsensusStateType {
+        self.0
+    }
+
     pub fn timestamp(&self) -> Time {
         self.0.timestamp
     }