Add ability for user to cancel all simultaneously running queries

[aeisenberg]

#462 introduced multi-running queries, where a user can select multiple queries and run them all at once. However, once initiated, a user can't cancel all queries at once, only individually. This is particularly problematic when a user kicks off lots of queries.

This issue is about enabling the user to cancel all queries in a single action.

An open question is, do we want to enable the user to cancel all running queries at once, or only the queries for the particular simultaneous run?

---

Update

Here's a summary and rationale behind the approach.

Right now the way we register vscode commands is ad hoc and spread throughout the code. (A command is just something that runs a function whenever you perform a keystroke combination or some other task). Because of this, each command is handling it's own errors (in a somewhat consistent way). Also, progress monitors are not applied consistently, so not everything is able to be cancelled. This refactoring is about extracting all this to a single location so every command is registered consistently and this refactoring will make it possible to use a single progress monitor when running multiple queries and allow all of them to be cancelled with one click.

[aeisenberg]

I was hoping for a simple implementation for this feature. Though, looking deeper, I think we need a refactoring to make it work. Currently, we create two progress runners for each runQueries command. The first is for compiling the query and the second is for running it. These progress runners are created in the actual calls to run/compile the queries. This is problematic since in the case of running more than one query, we are creating separate progress runners for each query.

Really, what we should be doing is creating the progress runner at the top-level, in the command execution itself and pass around the progress runner.

I'm proposing that we create a sort of command wrapper that we use for each command we run. The command wrapper will manage creating the progress runner, error handling, and telemetry (https://github.com/github/codeql-coreql-team/issues/475). The progress runner is then passed into the internal command functions if needed.

This should also make something like #534 easier to fix.

The difficulties are as follows:

1. Need to make sure that each command is properly async so that we can use await to wrap around any command invocation and handle any errors at the top-level
2. Possibly more boilerplate since we need to pass the progress notifier function around more often.

Though I think this change will have big benefits down the road as we can isolate a lot of our cross-cutting logic around job handling.

[aeisenberg]

@jcreedcmu ☝️ thoughts?

[jcreedcmu]

Ok, yes, this makes sense and I think the refactoring you're proposing is a good idea.

I assume when you say "create a sort of command wrapper that we use for each command we run" by "command" you mean "every codeql cli command". It's not 100% clear to me that for every command we need the ability to track progress, but for the ones we do, I agree we definitely should defer the creation of the ui progress view as late as possible so we can combine progress-trackable asynchronous operations together sensibly.

On the other hand, maybe uniformly providing the option of progress tracking for absolutely everything is fine and will make the code more uniform.

I think the concern I raised out of band about this interacting with #400 is not a problem after all; I think it's an orthogonal issue of what query execution does before and after the asynchronous cli call(s).

[aeisenberg]

The way I see it, in the command wrapper, a command can opt-in to an explicit progress monitor, but at least this gives us a uniform way of doing so. It also ensures we can properly use telemetry and error handling (though some commands require specific error handling for certain edge cases, which will have to be handled ad hoc).