Expand the In Memory event store to be able to run a real (example) app.

[leonm]

Goal

The goal of this PR is to get the In Memory Event Store to a state where it can be used in running example applications. It has some limitations but it can be used to demonstrate concepts without any dependencies.

The approach was to, as far as possible, follow the Postgres API so that the example store could easily be swapped for the real thing.

Config

Added an in-memory config class to be similar to the Postgres Config class. This allows search/replace of Postgres to Memory in environment.rb to switch between Postgres & Memory (plus deleting the database setup bits).

Projector

Added an in-memory projector that uses the in-memory config and follows the same API as the Postgres projector. Also adds a no-parameter constructor so that Postgres can easily be replaced with in-memory config (and the other way around).

Listeners

Added listeners to the in-memory store so that the event processors can be executed as part of the execution.

Limitations

• This requires all projectors to be executing in the same process as the in-memory store.
• Event processors are executed synchronously

[macosgrove]

I noticed recently that there's no Reactor class in Event Sourcery. It's defined in Event Sourcery Postgres. That really surprised me. It would be pretty difficult to experiment with an in memory app without Reactors. What does your app look like @leonm ?

I'm feeling quite uncomfortable with the split between ES and ES Postgres. Is it possible to aim for a split where we can inject an event store of the appropriate type by including the requisite gem, and have the app itself work the same regardless of whether it's Postgres or MySQL or In Memory or Oracle even?

That would mean moving these In Memory modules out to their own gem, at some stage. In many apps that gem could be included only for tests.