Bug 1479009

This idea arose on ML in relation to crm, but may be worth considering
for pcs nonetheless.  See the bottom part of:

http://oss.clusterlabs.org/pipermail/users/2017-August/006226.html

Technicalities:

1. I suppose such journal of what (logical, not necessarily 1:1, see
   below) pcs commands have been run would be dead-simple, local-only
   (otherwise there's this common risk pcs would need to come up with
   its own faul-tolerant cluster/peer network).  However, to allow for
   post-mortem entries correlation, there should be an extra field or two:
   - the originator of the command (user/pcsd), so that, for instance,
     a dedicated command (if any) can search back just through the real
     user entries
   - for the "execute-on-live-nodes in parallel", set an extra flag
     so that the journals can be correlated more easily, just looking
     at the entries like these

2. current accumulate-then-push method hides what really goes on when
   chunked (and possibly interleaved with custom sed commands and other
   out-of-band edits) and hence loses the continuity amongst the
   commands, should it be somehow recoverable;  alternative proposal
   from [bug 1359057] would, on the other hand, allow for much more
   solid expectation of what series of commands coupled together
   tightly (there could even be a checksuming incorporated into
   the "pipe protocol" to be 100% sure), hence these could be
   put into journal as an atomic block (compound command comprising
   particular pcs commands delimited with a pipe) at once, preserving
   readibility and (importantly) the intention

User-facing commands to work with such a journal can be added at later
stage, when it's clear what exactly would make sense.  I am currently
thinking more in the manual investigation intentions.