Set max timeout

[gjermundgaraba]

As per #88 (comment) we should have some kind of limit on the timeout.

Enforce a maximum timeout of 24 hours (just like ibc-go). This also solves the problem of accidentally using nanoseconds for the timestamp.

[srdtrk]

The limit should be same as that of ibc-go. If there is no limit in ibc-go, then we don't need to have a limit either. However, we wanna consider a large limit (days) due to aggregation use case. Same goes for ibc-go

[gjermundgaraba]

I think it makes sense to have a limit, especially as we move to seconds (and someone might by accident try to use nanoseconds). I think the limit can be relatively high, but should ideally error out if things get too crazy.

Input @AdityaSripal @womensrights?

[womensrights]

I think the limit set previously was 24 hours, I thought this was too high, but I wasn't thinking about aggregation, but assuming we would want to aggregate something like 25 - 30 packets, in the last 24 hours there were 11k+ transfers on cosmos hub, almost 39k on osmosis. I guess some of the smaller chains have 10s to 100s of transfers in 24 hours. I think this is reasonable, and can't imagine smaller chains having their own market maker for fast transfer, and then waiting 24 hours + for your packet to arrive doesn't make sense.

Also linking this issue as it is relevant cosmos/ibc#1146