Batching support

[fmterrorf]

In conjuction commanded/commanded#569 adds support for batching Ecto projections.

[cdegroot]

Note: review can wait until Calmwave has dogfooded this for a bit.

[drteeth]

Thanks for the work on this feature. It looks great, well done.

As this PR relies on upstream changes to Commanded, it will have to wait until that work is merged. See commanded/commanded#569

Before calling the PR done, the reference to the calmwave fork would need to be dropped of course.

[anderslemke]

I'm curious what the status on this is. What are the experience in Calmwave, @cdegroot ?

Also, I have a question:

Let's say I set batch size to 100.
Now, let's assume that the projection is up to date, and a new event is added.
Will I get the call to project_batch right away, or will it wait until we have another 99 events ready for the batch?

[yordis]

@anderslemke The subscription flushes on timeout (milliseconds) if fewer events are available, so batch_size: 100 won't wait for 99 more events.

[yordis]

I noticed a few issues with partial batch handling:

1. No event filtering - When a batch contains already-seen events (e.g., events [2,3,4] when watermark is 2), the user projection receives all events instead of just [3,4]. This can cause duplicate projections.

2. No locking - The watermark check and update aren't atomic. Two concurrent batches could both pass the check and cause race conditions.

3. Test verification - The test at lines 74-91 should verify that "e4" was actually projected, not just that the call succeeded.

The core issue is that apply(multi_fn, [multi]) at line 152 passes the multi but not the filtered events, so the user's lambda processes the original batch from closure scope.

A robust approach would be: lock → filter unseen events → update watermark → pass only unseen events to user projection.