Scenario overview:

* Canonical K8s cluster containing 2 nodes
* Dqlite data store (unable to obtain quorum)
* Primary node dqlite files stored on DRBD
  * sync block-level replication between the two nodes
* cluster monitoring and failover handled through Pacemaker

Script functionality:

* boostrap the service
  * wait for a DRBD primary to be elected
  * detect the node role based on the DRBD status and Dqlite state
    * have the replica wait for the primary to be ready before continuing
  * recover Dqlite after failovers
  * transfer and apply recovery files to secondary nodes
  * transfer Dqlite files to DRBD and other backup locations, creating
    necessary symlinks
* install required packages
* purge all K8s data
* clear Pacemaker taints
* remove recovery data

"2ha.sh start_service" is intended to be used as part of a systemd
unit that bootstraps the k8s services, coordinating with the other
node and taking any necessary steps to recover Dqlite.

We're adding a guide that covers the 2-node A-A HA scenario.