feat!(Streams): Support propagating Unfolds; remove StreamResult

[bartelink]

Enhances the pipeline to support propagation of Unfold events through the pipeline:

• EquinoxSystemTextJsonParser.eventsAndUnfoldsWhereStream extracts the unfolds in addition to the events
• StreamSpan.merge ensures we only retain the most recent ones as inputs are coalesced
• Handlers are presented any unfolds at the end of the span (assuming they fit inside the limit)
• Unfolds will always have an IsUnfold = true and Index = version, where version is the Index of the last 'real' event +1
• For Sync, EventStoreDbSink and CosmosStoreSink, the maxBytes limit will include/exclude either all or none of the unfolds
• Retries pick up the most recent unfold

As before, given a Propulsion.Sink.Event[], you compute:

• the index of the first event using Propulsion.Sink.Event.index
• the index of the next event using Propulsion.Sink.Event.nextIndex (even if there are unfolds at the end of the sequence)

Note that the following assumptions no longer hold if you have unfolds in an Event[]:

• nextIndex <-> index events + events.Length (renamed to next as intentional breaking change)
• actual events (not unfolds) count <-> events.Length

---

What is the use case? If you're running a ChangeFeedProcessor from an Equinox.CosmosStore, the changefeed includes:

• snapshots (which you could hydrate the state from directly without reading the store using Equinox)
• RollingState state as held in the tip

Being able to route the Unfolds to the Handler alongside normal events enables:

• complete copying of the content of a store in a single traversal via (propulsion sync cosmos or propulsion sync file cosmos)
• being able to run a sync job (or generic event handler) on a rolling state category
• being able to avoid Equinox reads of the source streams in the bulk of cases (as you can hydrate from the Unfolds instead of loading the state) using features in https://github.com/jet/equinox/pull/450

[bartelink]

but this would be a new major version since the user facing API seems to be changing

You are not wrong of course... But I have some buts:

This handler signature was only introduced in the V3 timeframe, and I believe it to have been a misdesign - you want calculating the next version (or having it flow from what the sycing is going into) be foremost in people's minds

For a V4, I think Propulsion.Feed and Propulsion should be merged as lots of modules depend on Propulsion.Feed and it in turn depends on Propulsion

What if I promised to mint a V4 as soon as Equinox.CosmosStore 4.1.0 is final ? (and kill Propulsion.CosmosStore3 the minute that's done)

Other things on the list that I'd like to do at some point (which don't change the V4 API but simplify the whole deal):

• align Propulsion.Kafka's Source mechanism with how all the other sources work (it has lots of ugly parallel implementations that are pretty close to what Propulsion.Feed generalizes for everything else
• other stuff in https://github.com/jet/propulsion/issues/116 like folding in the EventStore striped reading stuff into Propulsion.EventStoreDb