Simon Baslé

merged into `3.5.0-M6` via commit https://github.com/reactor/reactor-core/commit/ebfc60ab1de66aafe05fd85b9630e4f55dc8cd59

as there is currently no standard marble diagram representation of the Context, we won't provide a marble diagram for now

tentative commit message: ``` This commit introduces a ContextPropagation runtime-detection utility class as well as a `contextCapture()` operator. If context-propagation isn't on the classpath, this operator is NO-OP. If context-propagation...

edited this PR to rebase on 3.4.x and to amend the configuration so that the plugin can be found by mock gradle test

Unfortunately, it seems too late to address that one in time for 3.4, considering how late we already are in the pre-release cycle. Thus I'm moving this to 3.5 planning.

Depends-on: #3145

From the javadoc of the `trampoline` variant, it seems the expectation was that such an overhead was not needed for `subscribeOn` and `publishOn` operators (see [here](https://github.com/reactor/reactor-core/blob/c0a7bb8f4fce039dea2e40e7b9f6c06e9762aa28/reactor-core/src/main/java/reactor/core/scheduler/Schedulers.java#L132))

Could we simply change the documentation to state that executors MUST either execute in FIFO order or be passed to the variant with `trampoline=true`?

I guess there are two aspects to this: the default `fromExecutor` using the trampolining and the `fromExecutorService` underlying implementation needing similar trampolining in the first place. Is this a behavior...

there has been no activity around this in a while