Generate Tokio Runtime in ExecutionContext

[Dandandan]

Is your feature request related to a problem or challenge? Please describe what you are trying to do.

Currently a Tokio runtime is created outside of the control of DataFusion, and requires another user to specify a #[tokio::main] or a custom runtime.

The downside of this is that the config is outside of the control of DataFusion and depends on it being configured externally.

Describe the solution you'd like
Create a custom Runtime when creating the execution context.
Here we can also configure the worker thread count and max threads for the blocking thread pool based on a config or on number of CPU cores.

Possibly, for some usecases it would be nice to allow plugging in a runtime (e.g. when you want to share the runtime).

Describe alternatives you've considered

Additional context
Related to #924

[Dandandan]

FYI @alamb as this also has impact on IOx

[alamb]

If we go this approach, care must be taken to ensure any newly created executor does not interfere with one created with [tokio::main]

Here is an example of such a dedicated tokio executor that we made in IOx: https://github.com/influxdata/influxdb_iox/blob/main/query/src/exec/task.rs#L48-L65

I would be willing to contribute the DedicatedExecutor code back upstream to DataFusion if there is interest -- and we could add a configuration setting for thread counts, etc. I think the DedicatedExecutorcan also be used to satisfy the usecase of "running DataFusion CPU-bound tasks on a different thread pool than IO bound tasks"

[alamb]

In case anyone is interested: https://docs.rs/tokio/1.12.0/tokio/#cpu-bound-tasks-and-blocking-code

Is upgraded to say that using a separate tokio executor is not a bad idea:

If your code is CPU-bound and you wish to limit the number of threads used to run it, you should use a separate thread pool dedicated to CPU bound tasks. For example, you could consider using the rayon library for CPU-bound tasks. It is also possible to create an extra Tokio runtime dedicated to CPU-bound tasks, but if you do this, you should be careful that the extra runtime runs only CPU-bound tasks, as IO-bound tasks on that runtime will behave poorly.