Adjust `EntityMetamodel#CREATE_WITHOUT_LOAD` usage

[smcvb]

Enhancement Description

Pull request #4388 introduces the EntityMetamodel#CREATE_WITHOUT_LOAD ResourceKey to differentiate inside the DefaultEventStoreTransaction. It does so to resolve #4362, which marks the scenario where an entity is created without it being loaded first. This may occur when, for example, a command does not carry a @TargetEntityId for a creational command handler (which is a perfectly valid scenario).

Although this ResourceKey works, it's quite hacky. We jump from the EntityCommandHandlingComponent in axon-modelling, where this is set, to the DefaultEventStoreTransaction, where it is read. Ideally, the location where we know "we are going to create without loading" directs a path where we ensure the events get a workable AppendCondition for the tags from the published events.

One way to move the check earlier in the chain, is by adjusting the StorageEngineBackedEventStore#publish method to check for this ResourceKey. Added, we'd require a dedicated method on the EventStoreTransaction (e.g. appendCreateEvent), allowing the StorageEngineBackedEventStore to switch based on the ResourceKey. Although this improves things, we're stilling jumping from modelling-to-eventsourcing logic quite rigorously.

Another way forward might be to have a means to state "I want to publish an event with XYZ AppendCondition, right from within the entity OR entity meta-model.

Current Behaviour

We use the EntityMetamodel#CREATE_WITHOUT_LOAD resource key in the DefaultEventStoreTransaction to default the AppendCondition when tags are present.

Wanted Behaviour

There's an outward process telling the DefaultEventStoreTransaction "I want to publish creational events" or "I want to publish events with a given AppendCondition". Investigation should show which path is cleanest.

Possible Workarounds

None

[hatzlj]

An possible path could be to branch inside EntityCommandHandlingComponent#loadFromRepository when knowing we have a creational instance handler without identifier present and call an alternative path to org.axonframework.modelling.repository.Repository#load that propagates down to the EventStoreTransaction similarily as Repository#load does through EventSourcingRepository#load -> EntityLifecycleHandler#source -> EventStoreTransaction#source where the AppendCondition is set in the context.

Something like Repository#create -> EntityLifecycleHandler#create -> EventStoreTransaction#createStream

[smcvb]

An possible path could be to branch inside EntityCommandHandlingComponent#loadFromRepository when knowing we have a creational instance handler without identifier present and call an alternative path to org.axonframework.modelling.repository.Repository#load that propagates down to the EventStoreTransaction similarily as Repository#load does through EventSourcingRepository#load -> EntityLifecycleHandler#source -> EventStoreTransaction#source where the AppendCondition is set in the context.

Something like Repository#create -> EntityLifecycleHandler#create -> EventStoreTransaction#createStream

I was thinking about using the Repository#persist method here and there too, but didn't see a clear path yet... Perhaps the Repository#persist (which could act as the create) isn't fully suited for this yet. Or, I just didn't follow the right path yet.
But, good suggestion, @hatzlj! definitely worth investigating.