Add initial lifecycle and hooks into kubelet.

There will need to be a timeout. As Brendan pointed out, even systems like Android have timeouts.

In practice, different applications need different timeout values. Data processing workers with fine-grain shards may be able to complete their work and terminate in seconds. A stateless, load-balanced server may need to wait 2 readiness probe cycles to ensure the load balancer has redirected traffic. A database with an asynchronously updated backup may need a couple minutes to fully sync its state. A sharded service may need tens of minutes to spin up a replacement. A storage server may need hours to offload its data.

One could allow the timeout to be directly configurable. However, this could create priority inversion in a system where multiple levels of quality of service are supported. Observe in the examples above that the amount of time required to drain correlates strongly with possible quality of service levels. I recommend setting the timeout according to availability QoS level.

HOWEVER, users want different timeout values in different situations. For instance, they won't want to wait an hour if they just want to take down their service. We'll need all user-initiated operations that effectively stop containers to accept timeout values, which should override the default (assuming that they're smaller than the default).