Fixes #8863 - Provide a possibility to name virtual threads

[sbordet]

Reworked the VirtualThreads APIs to be based on Executor rather than just boolean.

Signed-off-by: Simone Bordet simone.bordet@gmail.com

[joakime]

Do we have a release with the old method names?
If so, this can't be removed, only deprecated.

[gregw]

I don't love it, as it is similar yet different to the pattern we've applied for TryExecutor.
Was there a reason we didn't just invent our own interface like:

interface VirtualExecutor
{
    void executeVirtually(Runnable task);
}

So we could follow the pattern of TryExecutor ?

[gregw]

It is a little strange that we have both an _executor and a _virtualThreadsExecutor, but use one or the other.

I guess we need the _executor when running with virtual threads and reserved threads, so the reserved threads can be started by the normal executor.

It would be nice if it could more closely resemble the _tryExecutor pattern.

[sbordet]

@gregw TryExecutor is an "internal" abstraction -- we do not allow users to set their own TryExecutor on an existing thread pool.

For virtual threads is different, we want to give users a way to pass their own virtual Executor which they can build how they want (e.g. with names, with ThreadLocals support, and all the properties that Thread.Builder supports).

We want also to support a "simple" way to configure this in Jetty modules.
Right now it's a simple boolean, but feels like we should have instead a threadpool-virtual.mod instead where we can configure the virtual Executor (with names, etc.).

WRT to AdaptiveExecutionStrategy, it's really an if/else: if virtual threads are enabled do this, else do that.
Before it was done with a boolean.

Even if from AdaptiveExecutionStrategy we call only executeVirtually(task), the QueuedThreadPool would have to do the if/else and delegate either to a virtual Executor, or to a itself as a non-virtual Executor.

I think we need 2 Executors because we want to give different names, and it's not only the names: the virtual Executor can be configured to not support ThreadLocals, etc.