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.
Do not do anything in monitor.rb recipe if there's nothing to monitor
Respect order of crowbar orchestration in recipes

The orchestration of the swift deployment is tricky, and crowbar does
several steps:
 - swift-storage (to discover disks)
 - ring-compute (to compute the rings)
 - swift-storage (to setup swift daemons)
 - swift-proxy
 - swift-dispersion

All of this starts falling apart (and causing failures) if a node has
several roles. So in each recipe, we also check the step we're in to
decide whether to go on with the recipe.

The way we identify the steps:
 - swift-storage (to discover disks): we have the role, but have not
   found the devices yet in the compile phase (works because
   swift-storage compile phase is run after the other recipes)
 - ring-compute: we have the role, and the rings are not on disk yet in
   the compile phase
Improve check for no disks on storage node

Some disks that we mark as "to use" are actually ignored later on if
they already have a partition not created by us. So we should check for
the disks after this.
Merge pull request #229 from vuntz/compute-reorg

Try to make the complex orchestration of swift more solid
Do not force people to use the swift-dispersion node

This role is optional. And people won't be able to assign more than one
node, thanks to the constraint (that is used for validation too).
Merge pull request #236 from vuntz/no-mandatory-dispersion

Do not force people to use the swift-dispersion node
Do not select Swift proxy node as storage node

When one node had a controller role set, it was
select as storage node as well. Skip it, to preserve
behavior of non-role layout.