Investigate alternative ways of handling snapshots to avoid race conditions

[SvenHoeffler]

Due to the asynchronous nature of emitting snapshots, a connector has no way of knowing whether an emitted snapshot was successfully stored in the snapshot repository.

In the worst case, this an lead to race conditions when the snapshot service is overloaded or the component takes a particularly long time to execute before emitting a snapshot. In those cases, the next execution of a polling flow could happen before the snapshot is stored, leading to component working off of outdated information and e.g. emitting the same data repeatedly.

A potential workaround could be expanding the ferryman to inject an alternate, synchronous function for storing snapshots. That way, a component could ensure that a snapshot was stored properly before continuing with further execution.