Create postgresql password in barclamp, not in cookbook

This way, it can be shared among multiple nodes.
Remove setting api_bind_host attribute in barclamp

This is unused.
Do not change db_maker user at every chef run

We were not using the right password to test if we could connect!
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 database 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
Include the HA recipe earlier

As we generate a config file based on a template in the directory that
will be the target for a mount when using HA, we need to get this mount
handled early.
ha: Only run the psql commands if postgresql is running on this node

Otherwise, we're subject to races where we reach that code before the
node hosting postgresql is fully configured to answer to psql.
Wait for the shared storage/drbd mount to be started somewhere

If we're too fast, we could generate some files in the directory that
will be mounted to, before the device is mounted, resulting in the
database to use the wrong config files.
Split the HA code in two recipes for more reliability

Because postgresql has config files not in /etc but in
/var/lib/pgsql/data (which is inside the mount that we use for
postgresql storage when in HA mode), the setup is quite tricky to get
right.

We must first setup the storage bits of the HA, so that we can write the
configuration files in the right place.

Once we have the configuration files inside the mount, then we can
configure (and therefore start) the postgresql pacemaker resource.
Otherwise, we're having a race, with postgresql starting before the
mount is completed on this node.

In addition to that, we used to rely on postgresql starting to generate
some of the files (thanks to initdb). We now have to do that manually.

In the non HA mode, we didn't have that many issues with the order,
because we do not use a mount which might not be there when creating the
configuration files.
Switch to the OCF RA for postgresql
Wait for postgresql to answer before going on
Ensure that the mounted directory for HA is owned by postgres

Now that we wait for the mount to be there, we can actually do the
chown.
Hide HA configuration if no clusters are deployed
Add validation for proposal

We validate the database engine as well as the HA bits.
Add DRBD support for HA

Co-Authored-By: Vincent Untz <vuntz@suse.com>
Split the colocation / order constraints

Since we first create the filesystem-related pacemaker resources and
then do some actions on the filesystem before creating the other
pacemaker resources, we need to have the constraints in place forthe
filesystem before we do the actions on the filesystem.
WORKAROUND: cleanup the resources
Stop monitoring postgresql through the IP address and with a password

The password is not correct the first time, which can result in some
issues.