Initial support for HA by assuming shared storage

We do not handle in any way the shared storage here; it could be
something to look at.
Add ability to use shared storage
Use new synchronization helpers to avoid races when deploying with HA

This helps avoid races when creating the pacemaker resources, either
because rabbitmq is not installed on one node yet (resulting in the
pacemaker resource not being runnable on that node) or because the
pacemaker resources are created at the same time on multiple nodes.
Use new Chef::Provider::CrowbarPacemakerService provider
On HA, wait for the vhostname to be defined in DNS

The rabbitmq daemon needs the vhostname to be resolvable, so we wait
for that before starting the pacemaker resource.
Force a DNS update in apply_role_pre_chef_call for HA

The virtual hostname needs to be resolvable for the cookbook to
successfully run.
Ensure that the mounted directory for HA is owned by rabbitmq

We wait for the mount to be there, which then allows us to do the chown.
Move the wait for the DNS update a bit later

It's not needed earlier, and this should allow us to wait less.
Ensure that UID/GID for rabbitmq is consistent on cluster nodes
Hide HA configuration if no clusters are deployed
Add validation for HA bits of proposal
Add DRBD support for HA

This is very similar to what was done for the database barclamp:
https://github.com/crowbar/barclamp-database/pull/67

Co-Authored-By: Vincent Untz <vuntz@suse.com>
Add ability to choose size of DRBD device

Since it's a LVM volume, we can't guess what's right and it's better to
leave it up to the user.
Wait for rabbitmq to start when use pacemaker

That allows us to make sure there's no issue with the pacemaker
resources, and not assume that everything is fine.
Merge pull request #28 from vuntz/ha

Active/Passive HA