phosphor-state-manager enhancements

[Andrew Geissler]

Since the creation of phosphor-state-manager and its representation of the
different bmc/chassis/host states, there has been a steady influx of requests
to provide more state and actions to these objects.

I'm starting to look into how best do this. There have been a few different
code and doc commits in this area, but they all seem to get stuck because
they break with the original design points of phosphor-state-manager. I'd
like to fix that. See [1] below for different requests I know of.

My concern is that if we don't address these additional state needs within
phosphor-state-manager, we'll just do it elsewhere, which causes redundancy
and makes it more challenging to share code.

The original design of phosphor-state-manager was to keep it super simple
and basically make it a wrapper around systemd targets. There was a large
focus on keeping the different objects (BMC, Chassis, Host) separate to ensure
some day when multiple BMC's, Chassis's, or Hosts are added to a system, it
all would just work.

There are definitely some merits to this design:
- It ensures anyone can insert their services into the appropriate systemd
  targets without any phosphor-state-manager code changes required
- A direct mapping of phosphor-state-manager state to systemd target keeps the
  code very simple

Some drawbacks to this design though:
- Our systemd target design is complicated [2]. There are lots of targets that
  need to be understood to get services in the right spots.
- It provides very limited state information. BMC is ready or not ready, chassis
  is on or off, host is running or off.
- It provides limited control. Reboot the BMC, turn chassis on or off, start,
  stop, or reboot the host.

The design was that external entities could do the more advanced logic. Want
your system to hard power off, use the chassis object. Want to power cycle
your chassis, turn it off, wait, then turn it on. Want to know if it's
powering on, look at the requested state and current state and do the logic
yourself.

So what am I thinking? I'm thinking that we should at least represent a subset
of Redfish states. Here's the full list:

"Absent": "This function or Resource is either not present or detected.",
"Deferring": "The element does not process any commands but queues new
 requests.",
"Disabled": "This function or Resource is disabled.",
"Enabled": "This function or Resource is enabled.",
"InTest": "This function or Resource is undergoing testing.",
"Quiesced": "The element is enabled but only processes a restricted set of
 commands.",
"StandbyOffline": "This function or Resource is enabled but awaits an external
 action to activate it.",
"StandbySpare": "This function or Resource is part of a redundancy set and
 awaits a failover or other external action to activate it.",
"Starting": "This function or Resource is starting.",
"UnavailableOffline": "This function or Resource is present but cannot be
 used.",
"Updating": "The element is updating and may be unavailable or degraded."

Starting -> Could apply to Chassis and Host when they are powering on / starting
InTest -> Could apply to when a host is taking an NMI and collecting debug
Updating -> Could apply to BMC and Host when a firmware update is in progress

There is actually a PowerState associated with the ComputerSystem we could
enhance the chassis with as well (PoweringOn, PoweringOff)

And also, some Redfish ComputerSystem.Reset operations we don't currently
support:
- ForceOff, ForceRestart, PowerCycle
Note we do "support" these but only via multiple operations.

Should we try to capture more of the host states? Right now we capture those
in the BootProgress and OperatingSystemState sensors.

So anyways, before I went to far I figured I'd get a note out to see if others
have thoughts. How ingrained are the current states? Will adding new one's
have a large impact on other software?

Thanks,
Andrew

[1]
# add firmware update state to BMC
https://gerrit.openbmc-project.xyz/c/openbmc/phosphor-dbus-interfaces/+/26867

# Add PowerCycle and Reset to Chassis
https://gerrit.openbmc-project.xyz/c/openbmc/phosphor-dbus-interfaces/+/22270

# Additional host states (Started)
https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/22461

[2]
https://github.com/openbmc/phosphor-state-manager/blob/master/README.md
https://github.com/openbmc/docs/blob/master/architecture/openbmc-systemd.md