Refactor: based: Support CIB transactions

This commit implements CIB transactions in pacemaker-based. Upcoming
commits will implement CIB transactions on the library side for CIB file
connections and in the client API.

pacemaker-based now stores up to one uncommitted transaction for each
connected client. Each transaction is a queue of normal CIB requests.
If a client has initiated a transaction and an incoming request's call
options contain cib_transaction, the request is appended to the
transaction for later processing.

When a client commits a transaction, all requests in the queue are
processed in a FIFO manner until either a request fails or all requests
have been processed. Changes are applied to a working copy of the CIB.
If a request fails, the transaction and working CIB copy are discarded,
and an error is returned. If all requests succeed, the working CIB copy
replaces the initial CIB copy.

Supported requests are those that meet the following conditions:

• can be processed synchronously at commit time, with any changes applied to a working copy of the CIB (for atomicity)
• are not queries (because the state is atomic, and because we can't return output data)
• do not involve other nodes (because this is inherently asynchronous and usually non-atomic)
• do not affect the state of pacemaker-based itself (because this is difficult to implement atomically, and because transactions are intended for CIB modifications)

If the cib_transaction call option is given, the request's return code
at the client side (received synchronously or via an asynchronous
callback) is the result of adding the request to the client's
transaction. Due to atomicity, no replies or notifications are triggered
when individual requests in a transaction are actually processed.

The commit request itself behaves similarly to a replace operation,
sending a reply and triggering any notifications that are registered.
The init and discard requests also send a reply. Therefore, clients can
can check the results of init, commit, and discard via callbacks or
synchronous calls.

A client's transaction is freed upon disconnect or commit. The entire
transaction table is freed upon pacemaker-based shutdown.

Ref T185

Signed-off-by: Reid Wahl <nrwahl@protonmail.com>