Use new synchronization helpers to avoid races when deploying with HA

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

 - when registering the endpoint and creating users in keystone
Merge pull request #222 from vuntz/sync-marks

Use new synchronization helpers to avoid races when deploying with HA
manage HA-enabled services via clone LWRP
Merge pull request #221 from jsuchome/clone

manage HA-enabled services via clone LWRP
Add synchronization marks around the creation of pacemaker resources
Merge pull request #223 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 #225 from rhafer/keystone_insecure

Add insecure flag to keystone_authtoken config when required
ha: Follow convention for pacemaker resource naming
Merge pull request #226 from vuntz/ha-convention

Update pacemaker resource names + other conventions for HA
wakeup keystone before any other keystone action
Merge pull request #228 from jsuchome/wakeup_keystone

wakeup keystone before any other keystone action
Sort memcache servers in configuration

The order does matter according to the memcache documentation.
Merge pull request #230 from vuntz/sort-memcache

Sort memcache servers in configuration
Update for prepare_role_for_ha_with_haproxy API change
Merge pull request #231 from vuntz/api-change

Update for prepare_role_for_ha_with_haproxy API change
Move code around in ring-compute.rb recipe

The goal is to make the recipe look less messy.
Spacing fixes in ring-compute.rb recipe
Do not setup swift-proxy if rings are not present

If the rings are not present, then swift-proxy will just fail to start.

If we do not have the rings yet in the execute phase when trying to setup the
services, then it means the ring-compute node didn't push them yet or we didn't
manage to pull them yet. Since we know that swift-proxy will fail without the
rings, there's no point in doing anything.

This can happen for various reasons, but the most likely one is having the
periodic chef-client run occur on the swift-proxy node before the crowbar
chef-client run occurs on the swift-ring-compute node. We know that crowbar
will run chef-client on the swift-proxy node after the rings have been
computed, so we will have the rings and a chance to start swift-proxy later on.

https://bugzilla.novell.com/show_bug.cgi?id=872518
Change element_order

There are two changes:

 1) we want to run swift-dispersion last: it only makes sense to run
    this when swift is fully setup
 2) we move the second pass for swift-storage before swift-proxy. This
    will guarantee that calls to swift-proxy just after it's setup will
    work fine because the storage will be ready.