[informativeness] poor interaction between "pcs status" and systemd related tracking of the services

[jnpkrn]

1. as long as pacemaker.service depends on corosync.service,
   and pacemaker.service is enabled, it has zero value to
   know whether corosync is enabled or not

You can check that the former condition is true like this:

systemctl show -p Requires pacemaker.service | grep -q '[= ]corosync\.service' && echo "depends" || echo "does not depend"

but you, of course, shall rather use native Python binding rather
then spawning yet another process (the same actually applies to
any other interaction with systemd, and with high level pacemaker
API in the works, for that eventually as well).

---

2. as an exception to the above rule, and as another discovery of
   where pcs doesn't play right with systemd, if the unit is
   masked, it will render as disabled, but disabled != masked

---

All in all, instead of seeing

Daemon Status:
  corosync: active/disabled
  pacemaker: active/disabled
  pcsd: active/enabled

it would be substantially more helpful to see these variations
(non-exhaustive):

Daemon Status:
  core cluster stack: active/disabled
  - note: nodes will not be able to automatically rejoin upon reboot
          while you may prefer this automatic refresh of the capacity
  pcsd: active/enabled

Daemon Status:
  core cluster stack: active/MASKED
  - warning: corosync is masked, so it cannot be started even manually;
             unmask it to suppress this warning
  - note: nodes will not be able to automatically rejoin upon reboot
          while you may prefer this automatic refresh of the capacity
  pcsd: active/enabled

And for

Daemon Status:
  corosync: active/enabled
  pacemaker: active/disabled
  pcsd: active/enabled

better to display

Daemon Status:
  core cluster stack: active/disabled
  - warning: corosync is enabled while pacemaker is disabled;
             unify the decision to suppress this warning
  - note: nodes will not be able to automatically rejoin upon reboot
          while you may prefer this automatic refresh of the capacity
  pcsd: active/enabled

And for

Daemon Status:
  corosync: active/enabled
  pacemaker: active/enabled
  pcsd: active/enabled

rather this:

Daemon Status:
  core cluster stack: active/enabled
  - note: nodes will be able to automatically rejoin upon reboot
          while you may prefer investigating them first
  pcsd: active/enabled

And for

Daemon Status:
  corosync: active/disabled
  pacemaker: active/enabled
  pcsd: active/enabled

this

Daemon Status:
  core cluster stack: active/enabled
  - warning: corosync is disabled, but it will get started
             automatically as a dependency of (enabled) pacemaker;
             enable it as well to suppress this warning
  - note: nodes will be able to automatically rejoin upon reboot
          while you may prefer investigating them first
  pcsd: active/enabled

And for when the disrepancy of pacemaker.service not depending
on corosync.service there could be:

Daemon Status:
  core cluster stack: active/MISCONFIGURED
  - warning: pacemaker does not depend on corosync service, which
             is unexpected;
             fix that misconfiguration to suppress this warning
  - note: nodes will not be able to automatically rejoin upon reboot
          while you may prefer this automatic refresh of the capacity
  pcsd: active/enabled

You get the idea of how to turn not-so-useful diagnostics into
something truly helpful and actionable.