host and consensus state timestamp should not contain optional time field

[Farhad-Shabani]

Background

The Timestamp definition was primarily designed to handle the packet's timestamp needs. Since a packet’s timestamp can be zero, which means it's absent. Therefore, the struct ended up using a time field with the type of Option<Time>.

Problem Statement

This approach works fine for checking packet expiration. Though, when it comes to consensus states or asking a host for its timestamp, we don't expect them to return None, and the timestamp should always be available. However, this definition allows light client developers and ibc-rs integrators to pass a Timestamp { time: None } to the system.

An an evidence of that optional non-needed:
When examining how the timestamp of Tendermint consensus state is obtained, we never encounter a None timestamp. The conversion path is proto Timestamp → Time → domain Timestamp, so it always results in a Timestamp { time: Some(time) }.

Proposal

To address this, we should at least ensure timestamp availability wherever we call host_timestamp().

A better design would be to create a generic type and trait for the timestamp, so that hosts and light client developers can introduce their own time types. Not being forced to use Timestamp, which can be challenging to conform to. Additionally, this introduces unnecessary tendermint dependency to downstream projects, which could cause resolving conflicts.

Relevant issues

• Timestamp define: not be strongly coupled with the time in tendermint #180
• Investigate removing the dependency on tendermint-rs #459