Add support for request timeout propgation.

[cpuguy83]

Adds a new field to the Request type which specifies a timeout (in
nanoseconds) for the request. This is propagated on method dispatch as a
context timeout.

There was some discussion here on supporting a broader "metadata" field
(similar to grpc) that can be used for other things, but we ended up
with a dedicated field because it is lighter weight and expect it to be
used pretty heavily as is.... metadata may be added in the future, but
is not necessary for timeouts.

Also discussed using a deadline vs a timeout in the request and decided
to go with a timeout in order to deal with potential clock skew between
the client and server. This also has the side-effect of eliminating the
protocol/wire overhead from the request timeout.

[cpuguy83]

Side note, this explicitly does not support client-side context cancellation, which will require more effort.

[stevvooe]

LGTM

I think this fits the bill of the design.

Looking at it and back at the grpc wire protocol and the design of ttrpc, I am wondering if we really need to support generic metadata or can we just add a Deadline field. I may have been pretty wrong to suggest using the metadata fields to perform that, but its clear there is a cost of allocations (the map, the values wrapper, the slice and the value itself) over just having a field. Its up to you if you want to change to the simpler model and I'm sorry for the run around.

[cpuguy83]

I would like to support tracing propagation as well. So metadata doesn't seem bad... but again maybe dedicated fields would indeed help with allocations.

Was also wondering if this should be done with the interceptor pattern rather than automatically adding it.

[stevvooe]

Was also wondering if this should be done with the interceptor pattern rather than automatically adding it.

I think automating is fine. All of the grpc packages do it and it makes it a no brainer for users.

Yea, I think metadata is needed, but maybe not for deadline. It would be nice to omit the allocation when its not in use.

[cpuguy83]

After discussing this on Slack, decided to:

1. Use a dedicated field which saves allocations, is generally lighter weight, and timeouts are pretty important to a request anyway.
2. Use a timeout instead of a deadline to work around clock skew issues (grpc uses a timeout).

This PR has been updated with the requested changes.

[stevvooe]

LGTM

[stevvooe]

Let's get a test into containerd to make sure this is working as intended.

PTAL @dmcgowan @crosbymichael