Extract directly to the toolcache

[henrymercer]

Adding the CodeQL Bundle to the toolcache seems to take a surprisingly long amount of time. We haven't collected large scale telemetry yet, but here's some anecdotal numbers from looking at the logs on PR checks:

• Linux: ~10–15 secs
• macOS: ~15–20 secs
• Windows: ~2 minutes (!)

Therefore in this PR, we add a feature flag that extracts the CodeQL bundle directly to the toolcache, eliminating the copy to toolcache step completely.

I've tested the change by adding a PR check, temporarily modifying this to running 10 runs on each platform, and running this a bunch of times. Next steps are dogfooding this change internally using the feature flag.

Merge / deployment checklist

• Confirm this change is backwards compatible with existing workflows.
• Confirm the readme has been updated if necessary.
• Confirm the changelog has been updated if necessary.

[dbartol]

LGTM. Looks like a relatively simple change, plus some plumbing to pass the destination directory through to all the places the write the files.

On a GitHub-hosted runner, it looks like we'll still add the bundle to the toolcache, even though the cache will disappear after the job. Is this just because we have to put it somewhere, and we might as well put it in the toolcache for consistency with the less-common self-hosted runner scenario?

[henrymercer]

On a GitHub-hosted runner, it looks like we'll still add the bundle to the toolcache, even though the cache will disappear after the job. Is this just because we have to put it somewhere, and we might as well put it in the toolcache for consistency with the less-common self-hosted runner scenario?

Yes, pretty much. It's also consistent with the situation where the GitHub-hosted runner images have caught up to the latest version of CodeQL and the tools we want are already installed. Plus if anyone's still using a hardcoded toolcache path to find CodeQL, that'll still work.

[NlightNFotis]

Great!

Thank you for this change!