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.




> Also, do we have any issues or potential cases such that one event failing prevents others from being run? When we re-run "failed" events, would we dump all DB info that occurs after the failed event and regenerate it from the subsequent events?

I don't think that we have any event dependencies right now. Well, maybe one, in that we need a record in the ConsumerState table (comes from a Consumer.CREATED event) when. IIRC you handled that when you create a new Compliance record by creating a ConsumerState record if one doesn't exist, right?

I don't think we'll have an issue there right now though.

Events should be