Refactored our exceptions
Renamed error_handler to error_notifier (code is still backward compatible)
The promiscuous command exits with 1 on failure
Always disconnect rubyamqp when the reactor shuts down
Better exception trace for the workers
Resilient workers

We previously had an auto recovery on the rabbitmq connection by trying
to reconnect every 2 seconds to the broker.

This commit applies a different layer of resiliency.

When the app instance is serving requests while the amqp connection is
down, a Promiscuous::Error::Publisher exception will be
thrown with the message:

    FATAL (out of sync) Promiscuous::Error::Connection:
      Not connected while publishing #<Member email: "user1@example.com">

The user can recover out of sync documents from the log file.

The workers are now resilient to any exception thrown while processing
the payload. All exceptions such as code failures or mongoid
disconnections are retried with an exponential backoff by waiting 2^n
seconds between the n and n+1 try.
If the amqp broker connection was lost and recovered, the workers are
retried immediately.

At every exception, the user is notified and a message is logged.
Example of a log entry:

    [receive] (retrying in 16s) Moped::Errors::ConnectionFailure:
      Could not connect to a primary node

The recovery logic of the subscriber is quite simple since the amqp
message is not acked until the message is successfully processed.
To retry, the worker simply tells rabbitmq to resend any unacked
messages. During the bareback mode of operation, the worker swallows
all exceptions.

For the publisher worker, it's quite different since we are polling from
the database with a destructive operation. If the amqp broker connection
fails right after removing the psp flag from the database, the worker
tries to set the psp flag back on the document.
The same would happen if an attribute reader on the model throws an
exception.
With the a network failure in mind, losing both services simultaneously
is possible. In the worst case scenario, the publisher worker will
recover the out of sync document by retrying publishing the payload or
setting the psp flag back, whatever works first.
Messages are repeatedly logged during this mode of operation. Example:

    [publish] WARNING out of sync on #<Member email: "user1@example.com">

If the worker is shut down before being able to recover the document,
the user must re-sync.

Once the failure is recovered, the workers continue their normal mode of
operation as one would expect.

When the system is out of sync, the log file will in most cases contain
messages containing either "FATAL" or "WARNING" in them.

There is still a hole when publishing message right before the
connection to the broken is lost before as we do not get any sort of
confirmation. Once fixed, the system will "always" be able to detect
out of sync situations.

This behavior have been tested manually in all kind of scenarios, but is
lacking some integration testing :(
Version Bump