This prevents the manager from crashing on machines with many cores.

Signed-off-by: Gerd Zellweger <mail@gerdzellweger.com>

Signed-off-by: Gerd Zellweger <mail@gerdzellweger.com>

If an adhoc query is sent it will be handled in the same
tokio runtime that is running the webserver.

This raises the questions of how many cores the runtime should
have. Datafusion will need one task for each partition we're
reading from. And we have as many partitions as dbsp workers.
So maybe we should've just change HTTP_NUM_WORKERS from 4 to
`config.global.runtime_workers`. Except, this doesn't
quite help because if your query is very expensive like
`select * from table_with_100m`, all it's task run for
quite some time and starve out the HTTP request. So now
the UI no longer updates. Ok, so maybe it should
just be `workers*2`, but if workers is set near the amount
of CPU cores on the machine then we'll overprovision
the tokio runtime and that will slow things down too.
So for now we just set this to #cores on the machine by
not configuring it (this is the default).

Note aside, ideally we can just swap out the actix
runtime with `dbsp::runtime::TOKIO` which is what we use
everywhere else and this already uses the #cores
in the runtime to run the tasks.
However, this also doesn't work because the actix
API has a stupid bug in the interface.

I submitted a PR to fix this here:
actix/actix-net#599

So for now, we'll just have two tokio runtimes, with

Signed-off-by: Gerd Zellweger <mail@gerdzellweger.com>

Signed-off-by: Gerd Zellweger <mail@gerdzellweger.com>

Also add ability to abort request with Ctrl+C.

Signed-off-by: Gerd Zellweger <mail@gerdzellweger.com>

As opposed to sending them only once everything is computed,
which can take a long time.

Signed-off-by: Gerd Zellweger <mail@gerdzellweger.com>