Deliver queued notifications in the order they were received

[dwcullop]

SharedDeliveryQueue does not deliver in the order it received.

receipt  : A1, A2, Bx
delivered: A1, Bx, A2

Pending notifications are partitioned into a typed sub-queue per source, and DrainPending picked the next one with Bitset.FindHighest(). That selects by sub-queue index, not by arrival.

Reachable through the operators, not just by driving the queue directly. SynchronizeSafe(queue) creates a sub-queue per subscription, so in Page the page requests and the data changes land in different sub-queues and both mutate the same Paginator.

Change

- var sourceIndex = _activeBits.FindHighest();
- var active = _sources[sourceIndex];
+ var source = _order.Dequeue();

_order is a Queue<DrainableBase> holding one entry per enqueued notification, recording which sub-queue it came from. The payloads stay where they are:

_items.Enqueue(item);         // typed, struct, no allocation
_parent.EnqueueOrder(this);   // a reference that already exists

That part matters. The obvious alternative is one queue of type-erased notifications, but Notification<T> is a readonly struct, so queuing one allocates nothing today. Recording only the order keeps it that way.

Selecting by arrival leaves Bitset, FindHighest, SetActive, NotifyQueueRemoved, CompactIfNeeded, _sources and the per-sub-queue Index all dead. Bitset had no other caller.

Highest-index-first was deliberate

Newer sub-queues are children of older ones, and a child had to drain before a parent's delivery could dispose it. Arrival ordering drops that guarantee, so a disposed sub-queue's stale order entries get skipped when the drain reaches them instead. Third test covers it.

Tests

Two of the three fail on main:

Expected {"int:1","int:2","str:hello"}, but {"int:1","str:hello","int:2"} differs at index 1
Expected {"int:0","str:a","int:2","str:b","int:4"}, but {"int:0","str:a","str:b","int:2","int:4"} differs at index 2

The bug only bites when the queue holds more than one item, which needs cross-thread contention. Single threaded the reentrant path drains inline, so nothing is queued to reorder. That is why the suite passes without this.

Related

#1163 moves change batching out of the queue. Independent, but that batching was masking this one: everything in a drain cycle got folded into a single changeset before anything downstream saw the order. Same file, so whichever lands second needs a trivial merge.

[JakenVeina]

As far as the preservation of ordering goes, this looks right to me.

Feel free to ignore the bit about AggressiveInlining for now, as it's already littered throughout the rest of the class. But I figured I'd mention it.

[JakenVeina]

Per official docs, don't use AggressiveInlining unless you can back it up with benchmarks to prove it's actually beneficial.

Adding AggressiveInlining is probably one of a variety of optimizations worth exploring, once the API is settled and proven in the field, especially since this whole class is basically a hot path. But I agree with the docs, it's premature. Plus, the runtime is QUITE good at applying optimizations like inlining on hot paths.