delay_period is handled in the wrong unit

[soareschen]

Crate

ibc

Summary of Bug

In ibc-go, the delay_period field is processed as nanoseconds, but in ibc-rs, the delay_period is converted to and from seconds using Duration::from_secs and .as_secs().

Example of erroneous conversion:

• https://github.com/informalsystems/ibc-rs/blob/c05f9c16231216bcd3ab2e7ca07626eafc4c9d3c/modules/src/ics03_connection/msgs/conn_open_try.rs#L161
• https://github.com/informalsystems/ibc-rs/blob/c05f9c16231216bcd3ab2e7ca07626eafc4c9d3c/modules/src/ics03_connection/msgs/conn_open_try.rs#L178

Acceptance Criteria

• Change uses of delay_period in ibc-rs when converting to/from RawMsgConnectionOpenTry to use nanoseconds.
• The CLI will continue using .as_seconds() to display the result in seconds.

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate milestone (priority) applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned

[ancazamfir]

Good catch! We knew it's in nanoseconds but when we changed the CLI parameter from nanoseconds to seconds we introduced the conversion errors.
Was curious as I was testing this a lot, so did a quick test with correct units and all looks good. Because we were consistent in our conversion mistakes, the delay introduced in packet relaying was correct (for both recv packets and timeouts). We were just preventing the on-chain validation to catch any cases we weren't.