Implementation of a SLF4J MDC Context

[elizarov]

Reworked #403, integrated with #454, see #119

[oshai]

Thanks, I will follow this issue to see when it is integrated.

[elizarov]

@abendt A notable different of this PR from the original PR #403 is that when kotlinx-coroutines-slf4j module is in the classpath, then ALL coroutines reset MDC of the current thread to the one that is set in their coroutine context.

Even if you just do runBlocking { ... }, then the code inside will have its MDC reset. You need to explicitly do runBlocking(MDCContext()) { ... } if you want to capture MDC of the current thread and preserve it inside the coroutine.

This is a design decision I'm not entirely sure of, though. It creates side effects to the all code by a simple fact of adding kotlinx-coroutines-slf4j to dependencies.

Another approach would be to only update thread's MDC is the coroutine has MDCContext element in its coroutine context but leave it "as is" for coroutines without MDCContext element. It would mean that runBlocking { .... } preserves MDC of the thread it run in, but then an invocation like withContext(UI) { .... } that is run inside of runBlocking would suddenly "loose" MDC. This decision could also affect the design of PR #454 (cc @qwwdfsad).

[elizarov]

@abendt @qwwdfsad It is based on updated #454 thread local API. A usefull side effect of this change is that a plain runBlocking { ... } works as in the original PR #403 -- MDC context on the current thread is kept without changes.

[qwwdfsad]

Tests don't match our pattern testFoo.
MDC should be documented better, it's worth to reflect that MDC cannot be implemented dynamically

[elizarov]

@qwwdfsad I've updated test named and wrote more detailed docs for MDCContext.