Or all executors, bypassing the allow list.
`dd.trace.executor=com.MyCustomExecutor,com.OtherExecutor`
`dd.trace.executors.all=true`
Turns out in many cases, executors that we say we’re skipping, are still being traced because they extend from an already instrumented executor.
Should eventually revisit this to try and remove them.
Latest failure was on:
```
at ExecutorInstrumentationTest.#poolImpl '#name' reports after canceled jobs(ExecutorInstrumentationTest.groovy:202)
```
Some executors cannot handle tasks that have been wrapped into
`{Runnable,Callable}Wrapper` because they require certain subclass of
`{Callable,Runnable}` in order to work. We have a test that
effectively disables instrumentation for such executors.
This change makes sure that tasks that do not need to be
wrapped (which essentially means anything that is not lambda) still
get traced in such executors. One notable example of affected executor
type is `ScheduledThreadPoolExecutor`.
It was only working because it extends from ThreadPoolExecutor, but it uses a backing queue type that is incompatible. Scheduled execution submits to the work queue directly and will bypass the exisiting instrumentation.
Luca Abbati
Tyler Benson
Nikolay Martynov
Andrew Kent