Reliable Event Delivery

Good explanation of where this PR leaves us is on the public website: http://www.candlepinproject.org/docs/gutterball/reliable_events.html

Important changes made to EventSource for durable hornetq queues, and preventing duplicate messages that could be caused by server restart. (duplicate messages are still a possibility GB should be prepared for)

Event status added to gutterball, which combines with two phase event processing to hopefully limit the exceptions that could be thrown during event processing, and allow us to identify events that failed later.

Added a super-admin only API call GET /admin/queues to view the HornetQ (not qpid) queues we have configured and a count of the messages pending in each.




When async and other concurrency issues arise, I'd argue another state (or two) would be useful. Since the second update only happens after a successful run through the handlers, RECEIVED is also synonmous with a PROCESSING state. Setting it to an explicit ERROR state signals that not only is the event not currently sitting in the queue and/or being processed, but there was an actual issue with it.