Make auth in GitHubApiDetails optional

[mbg]

Related to #4198 (comment).

We currently have a few different scenarios for where we fetch CodeQL CLI releases from depending on the environment that the CodeQL Action is running in. The usual case is that the running Action comes from github.com/github/codeql-action and is running in a workflow on github.com. In that case, the token we have can be used with api.github.com.

The CodeQL Action may also be running on GHES or GitHub Enterprise Cloud with Data Residency. In those cases, the token we have is for the respective environment. Our logic for finding a release to download the CodeQL CLI from prioritises the more specific environments, but falls back to fetching a release from github.com/github/codeql-action if the release is not available more locally. In that case, we should not use the token to authenticate any requests made from the host instance to the GitHub.com instance.

Currently, for downloads, this is done with the help of getAuthorizationHeaderFor which tests whether a given url matches the GitHub instance represented by a particular GitHubApiDetails object, which also contains the token. The token is only returned if the url is a match for the GitHub instance.

We don't currently have an equivalent process for API requests from a different GitHub instance to GitHub.com, even though the GitHub.com API will accept unauthenticated requests for public resources (with much tighter rate limits than authenticated requests). This is, in part, because we use getOctokitOptions from @actions/github to construct OctokitOptions for the API client, which requires a (non-empty) token.

This PR tidies up some of the code related to this, but mainly replaces the (virtually unnecessary) call to getOctokitOptions so that we are constructing the OctokitOptions ourselves and allow no token to be provided. This is fine for Octokit. This relaxation of the requirements in our api-client.ts library isn't used here, but it will allow us to make some API requests from other GitHub instances to GitHub.com in the future when necessary.

Risk assessment

For internal use only. Please select the risk level of this change:

• Low risk: Changes are fully under feature flags, or have been fully tested and validated in pre-production environments and are highly observable, or are documentation or test only.

Which use cases does this change impact?

Workflow types:

• Advanced setup - Impacts users who have custom CodeQL workflows.
• Managed - Impacts users with dynamic workflows (Default Setup, Code Quality, ...).

Products:

• Code Scanning - The changes impact analyses when analysis-kinds: code-scanning.
• Code Quality - The changes impact analyses when analysis-kinds: code-quality.
• Other first-party - The changes impact other first-party analyses.
• Third-party analyses - The changes affect the upload-sarif action.

Environments:

• Dotcom - Impacts CodeQL workflows on github.com and/or GitHub Enterprise Cloud with Data Residency.
• GHES - Impacts CodeQL workflows on GitHub Enterprise Server.

How did/will you validate this change?

• Unit tests - I am depending on unit test coverage (i.e. tests in .test.ts files).
• End-to-end tests - I am depending on PR checks (i.e. tests in pr-checks).

If something goes wrong after this change is released, what are the mitigation and rollback strategies?

• Rollback - Change can only be disabled by rolling back the release or releasing a new version with a fix.

How will you know if something goes wrong after this change is released?

• Telemetry - I rely on existing telemetry or have made changes to the telemetry.
  • Dashboards - I will watch relevant dashboards for issues after the release. Consider whether this requires this change to be released at a particular time rather than as part of a regular release.
  • Alerts - New or existing monitors will trip if something goes wrong with this change.

Are there any special considerations for merging or releasing this change?

• No special considerations - This change can be merged at any time.

Merge / deployment checklist

• Confirm this change is backwards compatible with existing workflows.
• Consider adding a changelog entry for this change.
• Confirm the readme and docs have been updated if necessary.