ibc: fix timeouts: use client height and timestamp

[avahowell]

Previously, when processing timeouts, we used the client_processed_height and client_processed_timestamp data to determine if a timeout duration had elapsed:

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

Line 70 in c9d778c

if !self.packet.timed_out(&chain_ts, chain_height) {

However, those refer to a height and timestamp on penumbra when any client update for that client had last been processed:

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

Line 168 in c9d778c

state_key::client_processed_times(&client_id, &height),

This comparison is invalid, we should instead be checking against the timestamp and height of the last consensus state from the counterparty client. This PR does that. This was verified to fix the interchain test failures in #4634 .

Closes #4634

[conorsch]

Upon further discussion, we are confident that this logic is correct and should be merged. However, we suspect there may still be follow-up required: there are two types of relevant timeouts here, height timeouts and timestamp timeouts. The IBC withdrawal struct requires that clients specify both: https://buf.build/penumbra-zone/penumbra/docs/main:penumbra.core.component.ibc.v1#penumbra.core.component.ibc.v1.Ics20Withdrawal so we should have two test cases in ICT, ensuring that each timeout type is exercised. We've notified @jtieri of this and he's working on it now.

[conorsch]

However, we suspect there may still be follow-up required: there are two types of relevant timeouts here, height timeouts and timestamp timeouts.{

@avahowell if you have more thoughts on this, please make sure it's tracked in an issue, so we can follow up completely. Any further changes to the IBC packet handling will be consensus-breaking.

[conorsch]

Merging. As stated in comments, we may have more related changes once we perform further testing via ICT.