Introduction of a central agent for archipel

Archipel is a mostly decentralized system but some common features of orchestrators require centralized tracking of the vms and hypervisors, namely high availability, billing and more. This PR introduces some elements of centralization.

It has been tested only on a simulated environment using nested virtualization. The test code is added in a new folder ArchipelTest. It is a full integrated test environment for archipel agent. For now it covers only the central agent functionality.

Testing is required on a real hypervisor environment. Some UI work is also required.
Documentation draft :
https://gist.github.com/nicolasochem/4956799

PR details:

1/ The Central Agent
===============

Manages the central db. Code is in archipel-central-agent

Its files are totally separated from archipel-agent. Conf file for example is different.

The schema of this central db consists of an "hypervisor" table and a "vm" table. It replaces the previously existing vmparking database. The vmparking functionality is unchanged for now.

Use PubSub for keep alive event and more (ex : platform request will add an indication of which stats are required)
There can be several central agent  instances on the same pubsub but there will be one and only one active central agent at a time when becoming the central (or statring) it will re-query all entities, hypervisors and vms, to rebuild its database from scratch.
Several central agent instances need to share the same centraldb.sqlite3 through shared storage.

HOOK on IQ to read/write in the central database from the plugins

Check the keepalive for hypervisor to update the vm hypervisor status in central database.

2/ The Centraldb plugin
=================

Is the connecting point to central db from all hypervisors. code is in archipel-agent-centraldb

Every hypervisors centraldb plugin subscribes to the central agent pubsub whose purpose is to advertise periodically the central agent jid.

For Virtual machine entities : Register on HOOK definine/initialise to update the central dabatase and on terminate to remove from the central db (if not parked only).

For Hypervisor entities : Register on HOOK xmmp_authenticate to subscribe on pubsub events. From here, for each keepalive event received :

starting or force-update : update central db with all vm and hypervisor entities
keepalive : update last seen or stats if needed

Provides plenty of hooks to do every CRUD operation on central db. These commands will translate into iqs for read/write operations, sent to central db.

An exit proc is added where the function archipel_exit_proc is executed when the agent is interrupted. This function removes the hypervisor from the central db before archipel stops.

3/ Plateform Request plugin for central agent
================================

code is in archipel-platformrequest-defaultcomputingunit and archipel-agent-hypervisor-platformrequest

Here is how it works : you send an iq to central agent:
```xml
<iq xmlns="jabber:client" to="archipel-hyp-3.archipel.priv@archipel-test.archipel.priv/archipel-hyp-3.archipel.priv" type="get"><query xmlns="archipel:centralagent:platform"><archipel action="request" limit="10" /></query></iq>
```
It returns the score for top vms :
```xml
<iq xmlns="jabber:client" to="professeur@archipel-test.archipel.priv/professeur" from="archipel-hyp-3.archipel.priv@archipel-test.archipel.priv/archipel-hyp-3.archipel.priv" id="professeur-0.0474851987786-137" type="result"><query xmlns="archipel:centralagent:platform" /><hypervisor jid="archipel-hyp-2.archipel.priv@archipel-test.archipel.priv/archipel-hyp-2.archipel.priv" score="0.001431875" /><hypervisor jid="archipel-hyp-1.archipel.priv@archipel-test.archipel.priv/archipel-hyp-1.archipel.priv" score="0.003019" /></iq>
```
The score is based on
1. number of vms running
2. amount of free ram on the hypervisor

The free ram is written to central db every time the central agent sends a keepalive. This may be a big load on the central db but we'll see how it performs in real world.

I respected the architecture implemented previously : there is a dummy score computing file which is extended by the python egg "default computing unit". It is possible to build alternate computing methods in a different egg.

The computing unit tells hypervisors which statistics to choose, as central agent keepalive message advertises them (now free ram, but it could be anything else in the hypervisor_health db).
the client is sending the request. it's not implemented yet (maybe a "new vm wizard"). 


4/ VMParking plugin to archipel agent adapted to centraldb
===========================================

Park vm in central db so it don't exist anymore on hypervisor side

Previously it was using a shared sqlite file. All sqlite operations were in-band.

This has been adapted to work with read/write iqs. As a result, some operations are asynchronous.

Everything is backwards compatible. But the updated client should query the centraldb directly instead of passing through the hypervisor. Eventually, only park and unpark operations should remain.

5/ Test suite
=========
Code is in ArchipelTest

This should be moved to another repository. I will remove it before merge. For now it's more convenient for me.

All key functionalities of central agent are tested. There is a README  file.

Here is the current list of tests. For each tests, queries the central db sqlite3 file directly, checks that its state is consistent. It also parses for ERRORs in the logs.

```
Start test 1 : Hypervisors come online.
Start test 2 : Subscribe to hypervisor.
Start test 3 : Hypervisors are in central database.
Start test 4 : Create undefined VMs.
Start test 5 : Delete undefined VM by sending stanza to hypervisor.
Start test 6 : Delete undefined VM by sending stanza to vm.
Start test 7 : Define vm.
Start test 8 : Delete defined VM by sending stanza to hypervisor.
Start test 9 : Delete defined VM by sending stanza to vm.
Start test 10 : Create vms directly in parking.
Start test 11 : Unpark one vm in each hypervisor.
Start test 12 : Park vms using the hypervisor park command.
Start test 13 : Park vms using the vm park command.
Start test 14 : Unpark and start multiple vms in both hypervisors at the same time.
Start test 15 : List parked vms.
Start test 16 : Destroy and park multiple vms in both hypervisors at the same time.
Start test 17 : Graceful shutdown of the hypervisor, checks status is 'off'.
Start test 18 : Ungraceful shutdown of the hypervisor checks status is 'unreachable'.
Start test 19 : Restart hypervisor with vms, checks that vm xmpp entities are instanciated.
Start test 20 : When central agent is off, restart hypervisor, check that vms xmpp entities are instanciated.
Start test 21 : Hypervisor switches off and on and finds out one of its vms has been started somewhere else, deletes them locally.
Start test 22 : Live migration of offline hypervisor.
Start test 23 : Test score computing iq.
Start test 24 : Xml update in parking, should pass.
Start test 25 : Faulty xml update in parking, should fail.
Start test 26 : Delete all vms from parking.

```