feat: implement execution of benchmark jobs on GitHub trigger

[michael-johnston]

Description

On a GitHub event, associated with a PR, we want benchmarks associated with the package in that PR to be executed on our infrastructure

Motivation

This featured is defined in the benchmark requirements doc (docs/requirements/benchmark.md)

Proposed Solution

1. User opens PR
2. At a point in PR reviewers request the benchmark via GitHub command e.g. /run-benchmark
3. This triggers a GitHub action which creates a benchmark "job" specification, which then is pending
4. A Github Runner, executing on our infrastructure, on a schedule, retrieves pending benchmark jobs
5. The runner pulls the relevant PR and constructs using the job spec the ado explore operation and runs it

What needs to be placed in the job specification and what can be inferred at ado job creation time TBD

Alternatives Considered

An alternative which

1. PR is merged
2. PR merge GitHub action triggers - on of these is run-benchmark, which creates the task
3. the GitHub runner on our arch is performing a long-polling on the benchmark tasks, it sees the task and pulls it
   • Tasks are queued so the runner will pull max one at each poll
4. (As step 5 above)

The event could also be on deployment event, release event etc.

[AlessandroPomponio]

I would be extremely careful with this, as there are many security considerations to be done:

1. GitHub itself recommends not using self-hosted runners with public repositories: https://docs.github.com/en/actions/how-tos/manage-runners/self-hosted-runners/add-runners

   We recommend that you only use self-hosted runners with private repositories. This is because forks of your public repository can potentially run dangerous code on your self-hosted runner machine by creating a pull request that executes the code in a workflow.

   For more information, see Secure use reference.

2. Self-hosted runners can be disabled at any time via organisation settings: https://docs.github.com/en/organizations/managing-organization-settings/disabling-or-limiting-github-actions-for-your-organization#limiting-the-use-of-self-hosted-runners

At the same time, the use of GitHub hosted runners is out of question given the potentially long execution times of tests, which would exceed the quotas set for our organisation.

In the mean time given the requirements in section 3.1 of #51 I have:

1. Restricted the creation of PRs to only collaborators
2. Enabled PR approvals/change requests only for users explicitly granted access to this repository (in the code review settings)

I would also suggest restricting interactions with the repository to only collaborators as well in the repository settings. cc @christian-pinto