Support scheduled commands in current context

[nik9000]

Adds support for scheduling commands to run at a later time on another
thread pool in the current thread's context:

Runnable someCommand = () -> {System.err.println("Demo");};
someCommand = threadPool.getThreadContext().preserveContext(someCommand);
threadPool.schedule(timeValueMinutes(1), Names.GENERAL, someCommand);

This happens automatically for calls to threadPool.execute but schedule
and scheduleWithFixedDelay don't do that, presumably because scheduled
tasks are usually context-less. Rather than preserve the current context
on all scheduled tasks this just makes it possible to preserve it using
the syntax above.

To make this all go it moves the Runnables that wrap the commands from
EsThreadPoolExecutor into ThreadContext.

This, or something like it, is required to support reindex throttling.

[nik9000]

I'm open to hearing that this is the wrong way to do it. I tried initially just interacting directly with the ThreadContext in reindex and it worked fine but the wrapping that EsThreadPoolExecutor did had such nice error handling that I wanted to steal it for us in reindexing. And copy and pasting code makes me sad, so we, yeah, that is how I got here.

[s1monw]

I like the way this is done. I think when we do issue commands they should by default inherit the context. Folks can still opt out by stashing the context in their runnable, no? Aside of this the cleanups are awesome

[nik9000]

I think when we do issue commands they should by default inherit the context.

I can flip that, sure. I think it is a bigger change but I can see if I can get it working.

[s1monw]

I can flip that, sure. I think it is a bigger change but I can see if I can get it working.

maybe we get this in as is and we can fix in a followup?

[nik9000]

maybe we get this in as is and we can fix in a followup?

I'm happy to do that as well.

[s1monw]

LGTM then

[nik9000]

Broke out the default behavior change into its own issue #17143.

[nik9000]

Merged as 80f638b