ibc: packet timeouts elapse, but withdrawn funds aren't refunded

[conorsch]

Describe the bug We believe that the Penumbra IBC implementation is not honoring packet timeouts on chain A messages.

To Reproduce

There are two ways to reproduce this behavior. The most comprehensive is to run ICT on the Penumbra integration branches and view the test failure: TK

A lighter approach is to test against the Testnet 77 (which has a Hermes relayer running on it):

1. Craft a withdrawal with an intentionally low timeout-timestamp: pcli tx withdraw --channel 8 --timeout-timestamp 5 100gn --to osmo1dlp27fw9ecdk6rwlxq4pqtjycheundlt09h7u7
2. Observe that balance is decremented by the withdrawn value, i.e. 100gn in the command above.
3. Wait a few minutes, check balance again, confirm that the withdrawn value remains decremented, when it should be refunded.

Expected behavior I expect that if I packet timeout is triggered on an IBC withdrawal out of Penumbra, then the withdrawn funds are refunded. That's not what we're seeing.

Additional context This problem was reported by @jtieri of SL, in the course of writing Penumbra integration for interchaintest.

[avahowell]

Note that the test here uses a timeout timestamp that is already expired for any chain; in this case we should just reject the tx to prevent users from sending a withdrawal that can never succeed. #4636 does this

[avahowell]

My current suspicion is:

• hermes and rly will never send a timeout for a new packet that is already expired (they have complex logic for tracking packets and this is an edge case that I doubt is covered well) (explains pcli failure)

• our timeout rounding requirement to prevent privacy leaks never got propagated to interchaintest, so their timeout test is just failing at the withdrawal level. (explains ICT failure, as no other chains have this requirement)

if the above is true then the fix is to merge https://github.com/penumbra-zone/penumbra/pull/4636 to prevent (1) from ever happening, and to work with SL to make sure that ICT quantizes their timestamps

[avahowell]

We found a separate issue that would prevent timeouts from being validated, see #4638