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
heat 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 heat for the
first time:

 - when creating of the database / database user
 - when registering the endpoint and creating users in keystone
 - running the db sync
Manage heat services via pacemaker clone LWRP

create clone resource for group, not for individual resources
Merge pull request #52 from vuntz/drop-db-node

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

Use new synchronization helpers to avoid races when deploying with HA
Merge pull request #48 from jsuchome/clones

Manage heat services via pacemaker clone LWRP
Add synchronization marks around the creation of pacemaker resources
Merge pull request #56 from vuntz/sync-marks

Add synchronization marks around the creation of pacemaker resources
Add insecure flag to keystone_authtoken config when required
Merge pull request #57 from rhafer/keystone_insecure

Add insecure flag to keystone_authtoken config when required
ha: Follow convention for pacemaker resource naming
ha: Do not pass is-managed / target-role meta when creating resources

We are happy with the default values.
Merge pull request #58 from vuntz/ha-convention

Update pacemaker resource names + other conventions for HA
Use heat-manage db_sync instead of python call
Run "heat-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.
wakeup keystone before any other keystone action
Merge pull request #60 from jsuchome/wakeup_keystone

wakeup keystone before any other keystone action
Update for prepare_role_for_ha_with_haproxy API change
Merge pull request #61 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)