[#4791] Extract snapshot sourcing composition into its own enhancer

[laura-devriendt-lemon]

Fixes #4791

Supersedes #4788, which added a handlesSnapshotSourcing() capability method to EventStorageEngine. That approach left two signals meaning "do not decorate this engine" with opposite precedence against a configured SnapshotStore, and let an engine silently override an explicitly registered one. This replaces it: the identity comparison stays the only signal, and the decision moves to the configuration layer, where a topology can take it over.

What changes

The snapshot-composition decorator moves into its own enhancer. SnapshotSourcingConfigurationEnhancer registers that one decorator and nothing else. EventSourcingConfigurationDefaults registers it during its own enhance(ComponentRegistry), so applications registering those defaults manually receive it too. It is deliberately not contributed through the ServiceLoader, keeping a single registration channel and avoiding a duplicate-registration warning on every module build.

The composition rule moves to a static factory. SnapshotCapableEventStorageEngine.decorate(engine, snapshotStore) returns the engine as is when it is the snapshot store itself, and decorates it otherwise. One home for the rule, reusable by a topology composing per shard, tenant, or region.

Disabling the enhancer becomes the supported opt-out. Documented on the enhancer and on the snapshotting page, with the consequence of disabling it without composing elsewhere spelled out: snapshots keep being written while never being read.

Bug fixed along the way

decorate(...) also returns an already-decorated engine as is, which fixes a defect on main. DefaultComponentRegistry.copyWithDecoratorsAndEnhancers() copies the parent's decorator definitions into a module registry, and that registry re-runs the copied enhancers, registering the same decorator a second time. The identity check passes for the second application, because the already-decorated engine is not the registered store, so a module registering its own EventStorageEngine and SnapshotStore got an engine decorated twice.

That redundant decoration costs a layer and a stream hop per sourcing, and silently ignores the second decoration's snapshot store. It does not cause a second snapshot read: the outer decoration rewrites the condition to an absolute one before delegating, so the inner one passes it through. A snapshot is therefore still read exactly once, which is why decoratesAModulesOwnEventStorageEngineExactlyOnce asserts the nesting rather than a load count. I first wrote it as a load-count assertion and it passed with the guard removed, so it would have proven nothing. The structural version fails with the guard removed, and only it fails.

The new enhancer carries @RegistrationScope(scope = CURRENT), so the defaults being copied into module registries do not register it again. Without it, every module build logs a Duplicate Configuration Enhancer registration warning: 41 of them in one eventsourcing test run.

Behaviour

No behaviour change for existing applications, and no EventStorageEngine API added. All ten pre-existing EventSourcingConfigurationDefaultsTest cases pass unchanged, including decoratesEventStorageEngineWhenSnapshotStoreIsDifferentInstance_evenIfEngineImplementsSnapshotStore — a separately configured SnapshotStore still wins, since implementing SnapshotStore still does not opt an engine out.

The new enhancer is deliberately public rather than @Internal: its class literal is the opt-out contract, so renaming it in a minor would break callers at compile time.

Motivation

A routing event storage engine that fans out to one engine per context, each composed with that context's own snapshot store. Decorating the routing engine consumes the snapshot sourcing strategy before any context is known, so the composed engines never receive it. Tracked internally as axoniq-framework#263.

Testing

SnapshotSourcingConfigurationEnhancerTest covers order relative to the defaults, decoration with a snapshot store present, the manual-defaults-registration path, the disable opt-out both through the registry and from an earlier-ordered enhancer (the cross-repo path, and the order-sensitive one), single decoration in a module registry, and no decoration without a snapshot store. SnapshotCapableEventStorageEngineTest.Decorate covers all three factory branches plus the null contracts. Full eventsourcing module: 542 tests, no failures.

[hjohn]

LGTM

[smcvb]

Looks good to me 👍