Closes https://github.com/sourcegraph/sourcegraph/issues/52493.

Here's a walkthrough of the changes. I think it's easier to think about it in this order rather than trying to parse the diff from top to bottom:

• We add a new method GitHubSource.DuplicateCommit [code].
  • This method is the glue around the client API interactions introduced in https://github.com/sourcegraph/sourcegraph/pull/52749.
  • It looks up the original, unsigned commit produced by gitserver, then constructs a payload for the "create commit" endpoint using metadata from that original commit and issues a POST request to duplicate it. If authenticated with the GH App installation token, this POST request will yield a signed commit.
  • Lastly, it updates the branch ref to point to the new, signed commit.
• We add another argument on to sourcer.ForChangeset to specify the preferred AuthenticationStrategy [code].
  • Most callers will invoke this method with AuthenticationStrategyUserCredential, which indicates using the "normal" method of authenticating a ChangesetSource with the user or site credential.
  • When the method is invoked with AuthenticationStrategyGitHubApp, if the ChangesetSource would be created for a GitHub code host, we will try to authenticate with a GH App instead (sourcer.withGitHubAppAuthenticator()).
  • This private method will look up if there is any batches GH App for this code host (gitHubAppStore.GetByDomain()).
  • If there is, it will authenticate the ChangesetSource with it as an installation.
  • If there isn't, it'll return an error.
  • Once authenticated in this way, any interactions with the code host through this ChangesetSource (such as creating new commits 👀) will be authenticated as the GH App installation.
• Finally, we hook into executor.pushChangesetPatch as the entry point to initiate the "duplicate commit workflow" [code].
  • In this part of the code, we already have a PAT-authenticated ChangesetSource for the changeset's repo that we use to create a git push config and push the commit with gitserver.
  • We let gitserver push the commit as normal. We retain the revision ref name (e.g. refs/heads/my-batch-change-branch) to use later to look up the commit, if we will be duplicating it.
  • We call a new private method executor.runAfterCommit with context about the operation.
  • If the ChangesetSource is for a GitHub code host, we try to authenticate a second ChangesetSource for it using a batches GH App.
  • If a batches GH App is configured for this code host, we should be able to authenticate this second source. This clues us in that we should try to sign the commit and proceed with the duplication via GitHubSource.DuplicateCommit().
  • If we weren't able to authenticate because there was no GH App, we break out and return like normal, preserving the original gitserver commit.

Test plan

Updated source tests and added new VCR tests for GitHubSource.DuplicateCommit.

Manually tested the whole workflow with a batches GH App and confirmed a branch with one signed commit was produced at the end: