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 case anyways.