MODE-2088 Eliminated the ring buffer's ability to submit entries in the same thread, which simplifies the consumers and makes them not need to be concurrent. Also changed the WorkspaceCache to register its own listeners that are better optimized for what they do. Kept the ability for the RepositoryChangeBus to have in-thread listeners (notified in the caller's thread), but these listeners only receive events via this route. Changed the JcrRepository to register various listeners directly on the bus rather than via the RepositoryCache (which was a listener and just delegated the register and unregister methods to the change bus). At this point, all tests pass successfully (multiple build passes).
MODE-2088 RepositoryChangeBus actually requires producers to be on multiple threads, and this was causing problems for the 'single-thread-producer' initial implementation. Added simple locking in the RingBuffer.add(...) methods, and verified that this fixes the sequencer problems.Interestingly, the time for my build is approximately 30-40 seconds slower (repeatedly) with the locking enabled, so we probably do want to consider getting rid of the locking but still supporting multiple producers.
MODE-2088 Created RingBufferBuilder utility that can handle more options, and added garbage collection to the ring buffer. The latter is a thread that follows all other consumers, nulling out the entries that have already been processed. This will reduce the overall footprint, even when the entry objects may be large. Garbage collection is optional and disabled by default.