fix(github)!: change automerge strategy priority order to allow platform signed commits

[pballandras]

Changes

This PR introduces a change in the way Renovate selects an automerge strategy/method for GitHub repositories. Previously it would test which merge strategy the repo allows and choose the first one available in this order in an if statement:

1. Rebase
2. Squash
3. Merge

This PR changes this to:

1. Squash
2. Merge
3. Rebase

Context

Discussion:

• Automerge strategy autodiscovery order and GitHub commit signing/verifying #32062

Why is the order important

The reason why the order is important lies in a limitation GitHub has when it comes to verifying/signing commits when merging PRs. More specifically:

When using the Rebase and Merge option on a pull request, it's important to note that the commits in the head branch are added to the base branch without commit signature verification.

https://docs.github.com/en/authentication/managing-commit-signature-verification/about-commit-signature-verification#signature-verification-for-rebase-and-merge

Since Renovate uses this method if there's no other configuration to explicitly change it in the repository, by default, it means the PRs Renovate merges won't be signed. Hence, this PR.

Documentation (please check one with an [x])

• I have updated the documentation, or
• No documentation update is required

Although I don't believe there are changes needed to the doc, if you feel like additions could be made somewhere I didn't think of, I'll gladly contribute.

How I've tested my work (please select one)

I have verified these changes via:

• Code inspection only, or
• Newly added/modified unit tests, or
• No unit tests but ran on a real repository, or
• Both unit tests + ran on a real repository

To test if the reordering would work I disabled some merge strategies to force Renovate into other branches of the if statement. With no surprises, the current order is respected and the interesting part is when Renovate squashes or uses merge commits (the merge strategy), the resulting commits are signed. Which is what is we want.

[CLAassistant]

All committers have signed the CLA.

[rarkins]

@pballandras thanks for this PR, but please create a Discussion first so we can discuss. I'll mark this PR as draft in the meantime. Please be sure to describe exactly which use case/scenario you find not be working today.

[pballandras]

I see you use semantic release and in the discussion you said you wanted this to be in a major release. I believe you can add it in the commit footer during merge, but do you need anything from me at this point? Thanks!

[rarkins]

Remove unused param

[rarkins]

@pballandras can you accept the change today? We want to release v39 soon.