Consumer signalling using generic sublist

[neilalexander]

This PR adds a new GenericSublist, which is based on the existing sublist, but with the following changes:

• No queue semantics — they are not necessary for straight-forward matching of generic objects;
• No cache — at the scale at which this produces a difference, none of the cache entries survive long enough, resulting in endless churn;
• No SublistResult allocations — the match function instead takes a callback, like SubjectTree does, making it effectively zero-allocation to use.

It also moves the stream mset.csl for filtered consumers over to the new generic sublist, such that consumer signalling for new messages and/or storage updates only touches interested consumers rather than all of them. This reduces CPU dramatically when there are a very large number of consumers on a stream with mostly sparse or non-overlapping interest.

Signed-off-by: Neil Twigg [email protected]

[derekcollison]

Nice improvement. For the CSL, I think a cache could help quite a bit, but maybe not L2 inside sublist but like we do for clients and the lock free L1..

[derekcollison]

In general LGTM

[neilalexander]

Have ported over relevant sublist tests and also rebased, so ready for final review & merge.

I can look at the idea of an L2 cache separately, but at the moment the current benchmarks don't show this as performing any worse than the current code does even without it.