ICS4: Receive, Acknowledge, and Timeout Packet should be structured to indicate already relayed messages

Currently, if N relayers relay on the same channel end, N-1 relayers will likely waste fees per packet relayed. This can be even worse if relayers attempt to retry relay attempt. Then it is N-1 * avgRetryAttempts wasted fees per packet

I am planning on adjusting the ibc-go code to indicate well known error codes for already relayed packets. This can allow retry attempts to be dropped. In the SDK, it may eventually be possible to use this mechanism to drop already relayed messages from the mempool

I'd be great if the spec could structure the receive, acknowledge, timeout packet checks in the same way to indicate the exact point at which a packet can be deemed as already relayed.

For acknowledge packet, this might be the place where the next send sequence > packet.sequence && packet commitment doesn't exist

Start with the ICS4 receive, acknowledge, and timeout packet checks, then review how the planned ibc-go and SDK handling would use structured results. Define the exact point at which each packet can be identified as already relayed and what well-known error information should represent it; completion requires the spec to document those checks consistently.

Written by the indexing model from the issue text.