[PLATFORM-1080]: Error handling

[cottinisimone]

https://prima-assicurazioni-spa.myjetbrains.com/youtrack/issue/PLATFORM-1080

I'm not totally sure this is an improvement. WDYT?

Pros:

• Aggregate::Error now just contains Aggregate related errors only (command validation)
• It is possible to simply understand between an Aggregate error and a Store error.

Cons:

• AggregateManager type is not so smooth (now is something like AggregateManager<PgStore<AggregateA>>) while before it was with aggregate only AggregateManager<AggregateA>.
• TransactionalEventHandler can return, in case you are using PgStore, a store error (sqlx or json) or a custom boxed error, not so easy to handle when returned being a generic std::error::Error.

[cpiemontese]

Minor comment on commented code

[cpiemontese]

Minor comment on commented code

[MatteoJoliveau]

Why is the PgStore generic over the Aggregate?

If this was simply PgStore and then implement EventStore<A> we could have one singleton instance of the store that can be reused in the application. With the current version we need a specific store instance for each aggregate, which feels redundant (yes, I know the underlying PgPool is still shared, I'm talking about the convenience and developer experience of having multiple store instances around)

[cottinisimone]

But event handlers and transactional event handlers sets are unique per aggregate..

[MatteoJoliveau]

Ah right... so as long as the store is in charge of the handlers it must be generic as well.

Bummers

[angelo-rendina-prima]

Minor Qs as discussed in a huddle with @cottinisimone:

• remove Clone from Aggregate::State
• remove Send/Sync bounds from Aggregate associated types (if possible, those should be in the EventStore really)
• for<'a> Aggregate::Event: 'a
• try RwLock instead of ArcSwap