chore: add automation for release keys

[nschonni]

Description

Either a test job in CI could run if someone touches the keys file, or a periodic sync can just check for changes and create a PR. I opted for the later, but the former would work as well.

Motivation and Context

#2569
I assume that a daily poll is more than frequent enough, although it's possible that a new Releaser could open the PR manually here while the other upstream PRs are waiting. Any sort issues would eventually get corrected by the PR this action would create.

Potentially the upstream documentation to open the PR here for the keys could be removed if this lands.

Testing Details

Example Output(if appropriate)

Types of changes

• Documentation
• Version change (Update, remove or add more Node.js versions)
• Variant change (Update, remove or add more variants, or versions of variants)
• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Other (none of the above)

Checklist

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING.md document.
• All new and existing tests passed.

[MikeMcC399]

I'm not sure if it should be part of the documented advice, but I would recommend disabling the workflow Automatically update Docker image versions before merging a PR with only key changes. That prevents immediate PR creation for a new Docker version release, and delays updating Dockerfile instances until there is an actual release using the changed key list.

[nschonni]

@MikeMcC399 I changed the cron frequency to weekly, and added a body parameter for the PR creation.
edit: First force push was missing the body, but fixed now

[MikeMcC399]

LGTM!

[MikeMcC399]

Running this workflow will fix the keys order difference described in #2569.

[nschonni]

@nodejs/releasers would it make sense to include your group as "reviewers" in the generated PRs for visibility, or would that just be noise?

[aduh95]

I'm not sure a cron is the correct way forward, a linter would be much better, avoiding "invalid" data to be merged in rather than correcting it after-the-fact

[nschonni]

@aduh95 I added a second plain CI/check action too. I can keep both, or drop the cron one if you think the releasers prefer to open the PRs here manually

[aduh95]

I'm not sure, an automated process makes it easier for a "bad" change to make its way here (i.e. someone getting write access to release-keys to affect docker-node); it really depends on thorough the review process actually is for this kind of automated PRs