Feature: fencing: remap sequential topology reboots to all-off-then-all-on

If a topology fencing request has a level with multiple devices, a requested
reboot should be remapped to all-off-then-all-on (consider the case of remote
power switches for redundant power supplies).

This revision implements the final step in the process: after all devices have
been turned off, turn them all back on again.

Individual "off" and "on" actions will use the appropriate action-specific
values for timeout etc. If "on" is required/automatic for a given device, the
"on" command will be left to normal cluster processing when the node next
rejoins the cluster.

Fencing will be considered successful if all "off" actions succeed.
If any "off" action fails, no "on" action will be attempted.
Any "on" failures or timeouts will be ignored.

The design maximizes interoperability with older versions (though that should
be limited to rolling upgrades). In a mixed-version cluster:

• If an older stonithd sends a sequential reboot request, it will not be remapped (the previous behavior will continue), and the originator might ask a newer peer to perform a reboot, even if that peer can only perform "on".

• If a newer stonithd remaps a reboot: an older peer chosen to execute a command will not use any action-specific timeout or maximum random delay; an older peer might be asked to perform "on" even if it's not allowed to; an older peer will never be asked to perform "on" even if it can, if it can't perform "reboot"; devices that are automatic or required for "off" may not get executed, and devices that are automatic or required for "on" may get attempted anyway.