…deprecated Gradle dependency declarations (#3088)

Co-authored-by: dkhalanskyjb <52952525+dkhalanskyjb@users.noreply.github.com>

* Make multithreadingSupported a property with a getter

This change fixes an issue with the initialization order observed when
lazy initialization is disabled (-Xir-property-lazy-initialization=
disabled compiler flag) and the new MM is used.

The problem is the following: the initialization of DefaultDelay
happens before the initialization of multithreadingSupported. Thus
the initialization of DefaultDelay gets an uninitialized value
of multithreadingSupported and behaves as if the old MM is used.

Related issue: #KT-50491.

Addresses #3109

The approach from 1.6.0 has proven itself as unstable and multiple hard-to-understand bugs have been reported:

* JavaFx timer doesn't really work outside the main thread
* The frequent initialization pattern "runBlocking { doSomethingThatMayCallDelay() }" used on the main thread during startup now silently deadlocks
* The latter issue was reported both by Android and internal JB Compose users
* The provided workaround with system property completely switches off the desired behaviour that e.g. Compose may rely on, potentially introducing new sources of invalid behaviour

The original benefits does not outweigh these pitfalls, so the decision is to revert this changes in the minor release

Fixes #3113
Fixes #3106

Instead of allocating an array of maxPoolSize (~2M) elements for the worst-case supported scenario that may never be reached in practice and takes considerable memory, allocate just an array of corePoolSize elements and grow it dynamically if needed to accommodate more workers.

The data structure to make it happen must support lock-free reads for performance reasons, but it is simple since the workers array is modified exclusively under synchronization.

Leverage the fact that `FutureCallback<T>.onSuccess` can only accept
`null` when `T` is `null`, to remove the unchecked casts.

… but still keep the pattern of the load roughly the same (#3147)

Fixes #3110

#3155)

* Confine context-specific state to the thread in UndispatchedCoroutine in order to avoid state interference when the coroutine is updated concurrently.

Concurrency is inevitable in this scenario: when the coroutine that has UndispatchedCoroutine as its completion suspends, we have to clear the thread context, but while we are doing so, concurrent resume of the coroutine could've happened that also ends up in save/clear/update context

Fixes #2930

…st… (#3161)

Addresses #3156

…he original exception prior to passing it to the Thread.currentThread().uncaughtExceptionHandler() (#3170)

Fixes #3153

* Update Dokka to 1.6.10

* Update Kover to 0.5.0
* Update robolectric to workaround robolectric/robolectric#5456 and then workaround all the update consequences

…low (#3185)

The details on how buffering conceptually works and what happens without subscribers are buried deep inside the SharedFlow docs. This clarification puts the important information right into the doc of emit and tryEmit methods.

Co-authored-by: dkhalanskyjb <52952525+dkhalanskyjb@users.noreply.github.com>

… service (#2957)" (#3190)

This reverts commit 0b65246.

Fixes #968
Fixes #548

#3199)

* Properly cleanup completion in SafeCollector to avoid unintended memory leak that regular coroutines (e.g. unsafe flow) are not prone to

Also, FieldWalker is improved to avoid "illegal reflective access"

Fixes #3197

Co-authored-by: Roman Elizarov <elizarov@gmail.com>

…3063)

Motivated by #3031

Updates the section "Coroutines are light-weight" to clarify its
comparison of the resource-intensiveness of coroutines and threads. The
content is much the same.

This commit also makes the code sample in this section runnable and
omits the surrounding runBlocking block.

… not meant to be a public mechanism (#3228)

The initial implementation predates new memory model and was never working on it

Fixes #3223

New approach eagerly copies corresponding elements to avoid accidental top-level reuse and also provides merge capability in case when an element is being overwritten. Merge capability is crucial in tracing scenarios to properly preserve the state of linked thread locals 


Co-authored-by: dkhalanskyjb <52952525+dkhalanskyjb@users.noreply.github.com>