class ShutdownManager

Theory of operation of ShutdownManager:

There are a number of ways shutdown can be initiated:

- The process could be terminated, resulting in a signal from the Lifecycle channel

- Any of the fidl connections could be dropped

These events can cause one of two stages of the driver shutdown to be triggered:

Package Shutdown: The shutdown manager signals the node_remover to shut down all package

drivers; ie: drivers that depend on storage and fshost.

Boot/All Shutdown: The shutdown manager signals the node_remover to shut down all drivers.

When the node_remover signals it has completed removing the package drivers,

The Shutdown Manager will transition to kPackageStopped. If something has signaled the

Shutdown Manager to shutdown the boot drivers in that time, the shutdown manager will

transition to shutting down boot drivers immediately after the package drivers are removed.

Otherwise, the Shutdown Manager will wait for an invocation of SignalBootShutdown before

shutting down boot drivers.

Either way, when boot drivers are fully shutdown, the Shutdown Manager will signal the

system to stop in some manner, dictated by what is returned by `GetSystemPowerState`.

The default state, which is invoked if there is some error, is REBOOT.

Any errors in the shutdown process are logged, but ulimately do not stop the shutdown.

The ShutdownManager is not thread safe. It assumes that all channels will be dispatched

on the same single threaded dispatcher, and that all callbacks will also be called on

that same thread.