Investigate an alternate mechanism for the bus/notification events

[sbrossie]

We have build our own internal bus event mechanism in Kill Bill to provide some very strong semantics, and in particular ensure that if any state has been changed, then an associated bus event will be sent. The implementation relies on two pieces:

• The guava bus event framework
• The persistence is implemented on top of our SQL engine -- mysql, postgresql, ...

We also support multiple configurations, some of them much more performant than others, mostly to address those 2 use cases:

• On Prem data center where instances are stable -- and same instance gets restarted after if fails
• Cloud deployment where instances may come and go -- and different instances are being rolled during deployment, expansions, ...

We would like to add a configuration to rely on some third part bus event systems. A good place to start would be activeMQ, but looking around for options might be good.

The work would be:

1. Implement the Queue interface to work with third part backend
2. Design/change current way of sending busEvents -- today this is mostly called from transactions, probably we need some other scheme, such as using a success transaction handler to post such events.
3. ... Down the line provide a docker-compose with activeMQ to bring up the stack.

The work would be similar for notificationQ, but maybe starting with bus events would be a good place.