Update db password migration script to remove node attributes

On update, we want to use the db password from the proposal / role, and
not the one that might have been generated on the node (through the
cookbook). As the password is a "normal" attribute on the node, but a
"default" attribute on the role, the old one from the node is used.
Which means we really need to remove it to get the new one used.

To minimize config changes, we actually import the password from one
node (which should be good enough in most cases as we allow only one
keystone proposal, so only one node should have the password).
Use new synchronization helpers to avoid races when deploying with HA

There are a number of possible races when deploying keystone for the
first time:

 - when creating of the database / database user
 - when finding the PKI info so it's the same on all nodes
 - when registering the endpoint and creating users in keystone
Merge pull request #199 from vuntz/drop-db-node

Update db password migration script to remove node attributes
Merge pull request #200 from vuntz/sync-marks

Use new synchronization helpers to avoid races when deploying with HA
use clone resources with LSB RA (for now)
use new Chef::Provider::PacemakerCrowbarService
Merge pull request #195 from aspiers/clone

manage keystone backend services via clone LWRP
Use new CrowbarPacemakerHelper helpers about the cluster founder
Move the end sync mark for the PKI creation a bit later

This way, all the code between the wait and create actions is related to
that. It doesn't change anything, except that the code feels more
logical now.
Merge pull request #201 from vuntz/is-founder

Use new CrowbarPacemakerHelper helpers about the cluster founder
ha: Follow convention for pacemaker resource naming
ha: Start the clone resource, not the primitive
Merge pull request #202 from vuntz/ha-convention

Update pacemaker resource names + other conventions for HA
Run "keystone-manage db_sync" on SUSE when HA is enabled

So far, we were not running it because the init script on SUSE does run
it. But with HA enabled, the service starts at the same time on all
nodes, which may result in failures on some nodes because db_sync can't
be run multiple times simultaneously. The end result is that the
pacemaker resource was possilby failing on some nodes, which then
required some manual cleanup.
Update for prepare_role_for_ha_with_haproxy API change
Merge pull request #204 from vuntz/api-change

Update for prepare_role_for_ha_with_haproxy API change
Only run the db_sync the very first time (on SUSE, at least)
Do the db sync only on initial run, and on all platforms
Merge pull request #203 from vuntz/db_sync-for-ha

Run "keystone-manage db_sync" on SUSE when HA is enabled