After the large reworks, I'm not as worried about having this timeout
anymore. Prior to the reworks stop was signaled via an async event sent
to the daemon as stop was performed directly on the given runtime-helper
instance. If anything errored during that it was common for things to
explode, but now that stop is:
client -> APIServer -> runtime-helper instance
and the logic for stop has been improved quite a bit, in addition to
stop no longer holding a lock during it's operation, I'm not sure we
need this. In the future it'd also be nice to support no timeout (the
timeout until we send SIGKILL, not response timeout) in which case we'd
have to have an extra bit of logic here to skip the response timeout in
that scenario anyways.
Today force deleting (if a container is running then stop()'ing first)
is handled entirely in the cli, which is brittle. The CLI doesn't know
if the container was started with --rm so it would have to do a weird
timeout + list dance to check if the containers gone after stopping.
This change remedies this by just having the daemon take in a `force`
boolean to the delete rpc. If this is provided and the container is
running then we'll stop first, and then cleanup. We can additionally not
cleanup if --rm was provided as the daemon has the data to determine if
a container asked for autoRemove.
0.5.0 introduces a new way to configure the containers and execs. This
is now done all upfront at constructor time in a callback style. I'm
very happy with the config improvements, but because IO can only be
setup at constructor time this makes it so that we need to supply IO at
creation time of the VM or exec, which isn't the end of the world. All
that really changes is `boostrap()` and `createProcess()` now take in IO
instead of slightly later in `process.start()`
J Logan