implement desired handling for reboot system call (used for halt & poweroff) inside container

Presently, no particular action is defined for the system call reboot when invoked from inside a container. (Generally, this system call supports not only rebooting, in the literal sense, but also similar requests, such as halting and powering down.)

For process supervisors (i.e. init processes) intended to run as a root process, an invocation of such a system call is often the final explicit action before entering a blocked state, in anticipation of a hardware event.

When such a call is made by the process running inside a container, it is desirable for the process to end immediately, with the effect of stopping the container from the perspective of the host daemon, even though the process may not reach a termination state by its internal control flow. Stopping a container is the analogous operation to rebooting or halting in a regular execution context (e.g. directly on the host).

Proposed is trapping an invocation of the system call reboot, and processing it by the host daemon as preemptive termination (i.e. requesting SIGKILL) of the process.

Such behavior would permit integration with an existing supervisor system, such as runit, that is otherwise well suited to container targets, without requiring customization of the code base to explicitly support optimal operation inside a container. Presently, this package may be operated inside a container, with a continue signal (SIGCONT) used to process a container stop event. The resulting behavior includes an undesired delay of up to 10 seconds after the process successfully tears down active services, until the container fully stops. This delay corresponds to the interval until the host daemon terminates the process preemptively after sending the specified signal.

Thus, optimal integration with runit would entail the following conditions:

1. The runit process is configured as the init process, that is, as the entry point.
2. The continue signal is configured as the container stop signal, sent to the runit process when the host daemon processes a stop event.
3. When the process receives the signal, it begins the teardown sequence, of the following steps:
   1. The runit instance stops active services.
   2. The process invokes system call reboot (with the modifier flag set for halt or power off actions, not necessarily a true reboot).
   3. The host daemon traps the system call.
   4. Processing the trap, the host daemon requests a kill signal for the runit process.
   5. The container stops, in advance of the 10 second timeout for the process not reaching a termination state. This result is desired, as no processes are continuing useful operations in the container.

Start by tracing the Moby host daemon's handling of container stop events and the reboot system call. The issue gives no file or test entry point, so first identify where system calls from containers are handled. Done means halt and poweroff variants of reboot cause preemptive process termination and avoid the described timeout.