Fix context propagation in Executor#execute() for non-capturing lambdas

[mateuszrzeszutek]

Fixes #9175

This is an interesting issue that only occurs when using a non-capturing lambda (or any other singleton/cached Runnable instance), and only when Executor#execute() is used (since all other ExecutorService methods typically wrap the passed task in a new FutureTask and delegate to execute() anyway).

Because a singleton Runnable instance was passed, the whole machinery in ExecutorAdviceHelper and TaskAdviceHelper that handles a stateful virtual field completely broke when trying to correctly update the PropagatedContext, and sometimes overwrote the propagated context with a null.

While this is a surgical fix that handles precisely the issue posted by the user, I believe we should rethink our executors instrumentation as a whole: I think instead of the complex and buggy state management we have right now we should switch to decoration whenever it's possible. While this will add a little bit of extra memory overhead, I think it's much safer that way.

[laurit]

While this is a surgical fix that handles precisely the issue posted by the user, I believe we should rethink our executors instrumentation as a whole: I think instead of the complex and buggy state management we have right now we should switch to decoration whenever it's possible. While this will add a little bit of extra memory overhead, I think it's much safer that way.

I think there was something that failed with the decorator approach. Some slick or other scala tests. If I remember correctly the issue was that it is possible to supply a custom work queue to ThreadPoolExecutor and they had used something that blew up on the wrapper types. I also believe that we should give using wrappers another go, perhaps we can detect when there is a custom queue and just not instrument these executors by default.

[xiangtianyu]

This can handle the "lambda" situation, but how about the singleton task?

[mateuszrzeszutek]

This PR does not fix that. We're planning to redesign the executors instrumentation and fix that issue across the board; but that might take a while and will not be included in the next release (which is in ~ 5 days).