Move change batching out of the delivery queue

[dwcullop]

SharedDeliveryQueue takes a callback that fires once per drain cycle, and CacheParentSubscription uses it as its only emit point. That is a batching policy living inside a class whose job is serialization. Raised on #1114.

It also batches more than intended. DrainPending drains whatever is queued, so work another thread enqueued mid-drain lands in the same emission.

Change

CacheParentSubscription tracks its own delivery frame:

private void EndFrame()
{
    if (--_frameDepth != 0)
    {
        return;
    }

    EmitChanges(_observer);
    ...
}

A child that emits synchronously during parent processing is delivered inline by the queue's reentrant path, so it nests inside the parent's frame instead of emitting separately. One upstream notification plus everything it triggers synchronously still produces one downstream changeset.

The callback then has no consumers, so the field, the overload taking it, and the invoke site all go. SharedDeliveryQueue only serializes now.

No lock around the depth counter. The queue has already serialized delivery, so only one thread is ever inside those methods, and the queue's lock is the barrier between drains.

The batching is load-bearing

EmitChanges is abstract and that callback was its only caller, so the six operators built on this class stop emitting entirely without a replacement.

Emitting per notification instead fails 34 tests, all on changeset granularity. ClearingParentEmitsSingleChangeSet gives 15 where it expects 2. OrderOfChangesIsPreserved gives 11 where it expects 2, and that one is more than a count: a single Edit doing Clear() then AddOrUpdate() has to arrive as one changeset, or the collection is observably emptied, which is a state that never existed upstream.

What actually changes

A second thread's work is no longer folded into the same emission. It gets its own frame.

Related

#1162 fixes the queue delivering out of receipt order. Independent, but this change exposes that one: once emission is per frame, delivery order becomes changeset order. Same file, so whichever lands second needs a trivial merge.

[JakenVeina]

Would it be crazy to say that this should be a StartFrame() or BeginFrame() method, just for the clarity that it pairs with EndFrame()?

Would it be even crazier to wrap up this logic in a private struct FrameTracker : IDisposable that does the tracking, and lets you just collapse it all to a using?