Serialize RPC deadline as a Duration.

[tikue]

Duration was previously serialized as SystemTime. However, absolute times run into problems with clock skew: if the remote machine's clock is too far in the future, the RPC deadline will be exceeded before request processing can begin. Conversely, if the remote machine's clock is too far in the past, the RPC deadline will not be enforced.

By converting the absolute deadline to a relative duration, clock skew is no longer relevant, as the remote machine will convert the deadline into a time relative to its own clock. This mirrors how the gRPC HTTP2 protocol includes a Timeout in the request headers but the SDK uses timestamps. Keeping the absolute time in the core APIs maintains all the benefits of today, namely, natural deadline propagation between RPC hops when using the current context.

This serialization strategy means that, generally, the remote machine's deadline will be slightly in the future compared to the local machine's deadline. Depending on network transfer latencies, this could be microseconds to milliseconds, or worse. Because the deadline is not intended for high-precision scenarios, I don't view this is as problematic.

Because this change only affects the serialization layer, local transports that bypass serialization are not affected.

Jaeger screenshot showing change in deadline between client and server:

Fixes #366

[ditsing]

Using the serialization layer to hide the conversion is pretty neat. Thanks for fixing this!

[tikue]

Thanks for raising this issue and providing prompt feedback, @ditsing !