Computation delegation using RabbitMQ and a daemon

# RabbitMQ authentication
/!\ final version pending discussion with our technical support group

 * add a key to app/parameters.yml.in similar to the "secret" / db password entries, that will be called consumer_key
 * create a random, long secret and add a key with app/parameters.yml with that secret
 * configure your RMQ bundle to use that secret as a password
 * use the study's ID as an identifier, so that a single RMQ daemon can authenticate study websites independently from one another; we can use that info to dispatch messages to the consumer that is appropriate for the format of the data being forwarded
 * give me a list of all the available options to ensure communication between Apache <-> RMQ <-> your daemon is encrypted.
 * tell me which you want to use and why -- i'll tell you if it's not acceptable security wise

# AppPartController: create action to log a login event

 * look up the structure of events by inspecting the data stored by the password client
 * write a GENERIC action in the controller that receives:
    * a string of data, which contains the clear-text password and all the relevant information for the client
    * a list of strings (maybe a comma separated string?) that acts as ids. The first id is the unique event id, the second id is a "resource" id which identifies the password; we keep that generic so the code can be reused in the future more easily.
 * for password-gb/cn we will generate a unique event id based on user id + url + password + timestamp, and we will use the hash of the logged password as a second entry to the ids' list, so we can identify both passwords and individual login events transparently. The daemon can use the ids to know if they already computed and cached results for a specific password, and for event/password deletion.
 * in that new controller action action, produce a RMQ message containing the data and ids, and ensure a timestamp is available for the consumer (either via protocol, or add one)
 * you must have seen that there is a setup function at the start of controller actions in my website, which performs access control... Make sure to use the same parameters as uploadAction or directUploadAction (to make sure we have participant consent before we let participants send us data).
 * inform client of any issue that can be synchronously detected (look up the structure of other messages to see how to report a failure)

# AppPartController: create action to delete data on the server side

 * in the controller action, collect the unique event id from the client and dispatch it to the daemon for now
 * the daemon will have to have data structures that point which password id is related to which event id, so that we know if the deletion of an event causes a password to be related to zero events (triggering deletion of the password's cached computations too)
 * improve the way the action works: allow clients to provide multiple ids in the following format: (<index in the id list>:<id value>, ...). Serialise this as you like. The idea is that clients can ask for the deletion of a password (and all its related events), or of a single event. Maybe later we want to let them delete a website with its own website ID, or a username... The website should be entirely generic and oblivious to this, only the client and daemon need to agree so we never need to touch the website code again.