Support Marten's "Separate Store" Functionality (finally)

[jeremydmiller]

See https://jeremydmiller.com/2024/04/15/modular-monoliths-and-the-critter-stack/ for a little background.

The Marten transactional boundary and/or aggregate handler workflow does not work today with Marten separate stores, and that's been a longstanding limitation.

The goal of this feature work would be to enable Wolverine handlers to target Marten separate stores.

Usage

On the handler class or on an individual Handle() method, decorate with [MartenStore(typeof(ICustomStore))]. We could talk about using conventions for things like "these handlers are in this Marten store", but that makes me nervous. That's the kind of magic that burns teams and following developers.

So:

[MartenStore(typeof(ICustomStore))] // you'd be able to sub class this, and the generic attributes would help later
public static class SomeHandler
{
    public static void Handle(SomeMessage message)
    {

    }
}

Maybe add the store type to [AggretateHandler] as well just to shorten things up

Tasks

• Add an IntegrateWithWolverine() to the separate store expressions
• Create new Wolverine-ized postgresql databases for the separate stores
• New OutboxSessionFactory<T> where T : IDocumentStore for the separate store. Shouldn't be any big deal
• New attribute
• Modify the transactional middleware
• Modify the aggregate handler middleware
• Add database schema for the separate store, including multi-tenancy
• Spin up durability agents for the separate stores
• Can use the outbox with the separate store

[jeremydmiller]

Notes on Implementation

• Go watch any hard coded reference to WolverineRuntime.Storage
• Don't even try to support Postgresql queues with the separate store
• No way today to choose a different session factory for separate store in Marten