Fast and scalable channels algorithm

[qwwdfsad]

In #3103 we propose a brand new underlying data structure for channels.
The change is technical and should not affect user-visible invariants, behaviour and API shape.
The full-blown algorithm description and correctness proof can be found here: https://arxiv.org/abs/2211.04986

The rework addresses the following problems:

• Previous implementation is based on a concurrent double-linked list, which has proven to be incorrect, hard to reason about and always impossible to maintain, meaning that linearizability issues and non-trivial data races cannot be fixed and reasoned about in a predictable manner
• The implementation also imposes non-trivial limitations on both bytecode and dex size due to its complex implementation details
• All non-trivial operations are expressed in terms of descriptors (DCAS, N-word CAS) that limit both scalability, correctness and performance characteristic

Additionally, it's well-known that array-based data structures significantly outperform linked structures, while fetch-and-add algorithms outperform CAS-based ones. Both of these facts are acknowledged by the new implementation:

• New channels are 10-25% faster on sequential (the most important for Android and slightly loaded systems) scenario
• New channels are by an order of magnitudes faster for workloads that are dominated by communicating channels
• New implementation also unlocks Optimize CancellableContinuationImpl.invokeOnCancellation(..) for Segments #3084 that will enable fast-path allocation-free channels

[qwwdfsad]

This issue is also a final straw for the *BroadcastChannel deprecation -- broadcasts were never meant to be complete channels (-> comply its interface) and it's time for us to let them go and stop maintaining them

[qwwdfsad]

After #3084 our performance-related outline is the following:

• Any loops over channel contents (including repeated send as well as receive) are, on average, allocation free, even if every operation suspends). No CancellableContinuation (it's cached in loop's state machine and allocated once), no cancellation handler (its cached in CC instance), no intermediate list nodes (nodes are batched, an allocation every 64 operations)
• Average operation throughput in sequential scenario for rendezvous is at least 35% higher, while allocation rate is significantly (no number us depends on your workload) lower. It's kind of conservative to assume that amortized channel's influence on system throughput is reduced in half
• Thanks to optimized data-structure (fadd-based arrays vs "6-CAS DLL"), contended throughput is magnitudes higher. I won't post any numbers, as they are really subjective to benchmark (because we measure stressed out channel, which is unlikely to be realistic in real applications) and looks unrealistic anyway :)

It seems like we have no other low-hangning fruits in channels.

[ndkoval]

Also, a customized ChannelSinkBenchmark for buffered channels (capacity=BUFFERED) suggests x1.7 speed up on my laptop 💪