Check that IBC handlers don't short-circuit misbehavior handling

[hdevalence]

Describe the bug

While discussing cosmos/ibc-go#6159 , I mentioned our IBC implementation's short-circuit behavior, and @srdtrk pointed out that there's a possibility that this causes us to not handle misbehavior correctly:

The reason why we don’t quit so early like penumbra is because we check if UpdateMsg actually is evidence of misbehavior. (The check should be done imo)

We should audit the code and ensure that our short-circuiting behavior doesn't prevent this.

A fix for this issue is either:

• An explanation of why we handle misbehavior correctly despite our short-circuiting (if this is the case)
• A fix to handle misbehavior correctly (if it was not correct)

[srdtrk]

In ibc-go, we have a legacy message server for misbehavior that is deprecated. We now use MsgUpdateClient to check for misbehavior when there is a duplicate client update with conflicting headers.

I see that penumbra has a non-legacy misbehavior handler. Nevertheless, it is better to do this check in update client so that misbehavior is handled even if the relayer doesn't know that there is a misbehavior.

[avahowell]

We do perform this check for misbehavior (a duplicate header with different state) in UpdateClient:

penumbra/crates/core/component/ibc/src/component/client.rs

Line 37 in 50d1643

// if we have a stored consensus state for this height that conflicts, we need to freeze

[avahowell]

The short circuiting behavior for client updates will only short circuit in the event where we already have a header for the provided height, and the consensus state for the stored header is identical to the one contained in the update:

penumbra/crates/core/component/ibc/src/component/msg_handler/update_client.rs

Line 186 in 05366eb

Ok(stored_tm_consensus_state == untrusted_consensus_state)

So, if a relayer provides an equivocation to the update handler, update_is_already_committed will return false, and the rest of the update handler will continue to next_tendermint_state which will set the next state for the client as frozen due to the equivocation.

Closing this issue for now since I think this addresses the concern raised