Ensure events with both Create and Apply are only ever handled once

[elexisvenator]

Fixes #2528

Expected outcome: Each event passed into a projection is handled a maximum of once, either with a Create or an Apply method.

Old behaviour: If the first event in a stream has matching Create and Apply methods, both would be called.

New behaviour: If a Create method matches, that event is then skipped when iterating over apply event methods.

Example of issue:

    public record IncrementEvent{}

    public record CounterProjection(Guid Id, int Counter)
    {
        public static CounterProjection Create(IncrementEvent @event, IEvent metadata)
        {
            return new CounterProjection(metadata.StreamId, 1);
        }

        public CounterProjection Apply(IncrementEvent @event, CounterProjection current)
        {
            return current with {Counter = current.Counter + 1};
        }
    }

    [Fact]
    public async Task count_of_events_should_match_event_count()
    {
        var streamId = Guid.NewGuid();
        theSession.Events.Append(streamId, new IncrementEvent(), new IncrementEvent(), new IncrementEvent());
        await theSession.SaveChangesAsync();

        var aggregate = await theSession.Events.AggregateStreamAsync<CounterProjection>(streamId);

        Assert.NotNull(aggregate);
        Assert.Equal(3, aggregate.Counter); // Returned 4 before fix
    }

This required a bit of fiddling around with the codegeneration which I am definitly not super confident in. Pretty sure my changes are solid thanks to the tests covering them, but my approach may be off.

[oskardudycz]

This looks good to me in general, but I'm unsure if when we have #2560 then if that'll be needed. Having static Apply method capabilities could be enough, as it will do upsert. The logic in this PR seems okay, but it'll add more magic to the usage pattern. @elexisvenator, @jeremydmiller thoughts?

[jeremydmiller]

I'm asking #2560 to be changed, and I see this as orthogonal anyway. Good stuff, I'm pulling this in now.

[agross]

Is this included in Marten 6.0?

[mysticmind]

Is this included in Marten 6.0?

yes @agross!

[agross]

I was asking because after upgrading to 6.0 I tested this.

The second transaction affecting the projection still calls Create first and Apply second (like it did before 6.0 was released).

Since the test above models a single transaction, could this be the reason why it does not work in my use case? 🤔

[mysticmind]

@agross unsure, please do share a repro code for us to check.

[agross]

@mysticmind See #2528 (comment)