deliver anti-events when pruning

[rkuhn]

When #388 is done, users will be able to place app events into ephemeral event streams, leading to them getting pruned. Currently, this happens without informing apps that have running subscriptions or stored state snapshots, meaning that admins need to carefully consider to only prune events where no inconsistencies can arise.

The easiest way to erase inconsistencies is to emit anti-events for those events that are being pruned. This should nuke state snapshots as well as lead to time travel for machine-runner.

Implementing this requires changes to (or audit of) the Actyx SDK and Pond in order to ensure that anti-events are correctly understood. We’ll also need to test what happens when a new Actyx version emits anti-events to an old Pond app.

[rkuhn]

A large part of this problem is already solved by subscribeMonotonic: when an old event goes away, there will be a timeTravel notification with the appropriate event key, taking care of rebuilding Fish or machine state.

The only place needing more anti-events is running subscribe queries, which can now emit them even without using AGGREGATE (and AGGREGATE implementations may need to restart from scratch, in particular for FIRST(_)).

[jmg-duarte]

Start by understanding the subscribe infra and live events