feat: Suggest missing changes across current/next versions

[pepopowitz]

Description

Partially addresses #1778. A proper implementation of #2922.

This is the first iteration, with a subset of version recommendation rules.

Adds a workflow that comments on a PR when changes were made in next but not current, or vice versa.

What the message looks like

When there are suggested changes:

When suggested changes have been satisfied:

Test cases

Test PRs were created based on this branch to demonstrate behavior in a variety of scenarios:

• No suggestions (no changes in current or next) [DO NOT MERGE] test PR: No suggestions (no changes in current or next) #3092
• No suggestions (changes in current are also in next) [DO NOT MERGE] test PR: changes in current & next #3104
• Changes made in main current but not main next [DO NOT MERGE] test PR: changes in current but not next #3093
• Changes made in main next but not main current [DO NOT MERGE] test PR: changes in next, but not current #3105
• Changes made in optimize current but not optimize next [DO NOT MERGE] test PR: changes in Optimize next, but not Optimize current #3106
• Changes made in optimize next but not optimize current [DO NOT MERGE] test PR: changes in Optimize current, but not Optimize next #3107
• Multiple changes suggested in one version [DO NOT MERGE] test PR: multiple changes missing in one version #3108
• Multiple versions suggesting changes [DO NOT MERGE] test PR: multiple versions suggesting changes #3109
• Changes suggested, then satisfied [DO NOT MERGE] test PR: suggested changes resolved #3112

Not included

Forked PRs. I ran into issues with checking out the correct SHA in #3111, due to changing the workflow to run on pull_request_trigger. I reverted this workflow to run on pull_request.

I'll try to make this run for forked PRs in the future. Running it on Camunda/internal PRs will likely help 98% of PRs, and we look at forked PRs with a more scrutinous eye anyway.

Implementation notes

• The workflow gathers a list of all changed files in the PR, and checks for equal presence across the versions. It does not validate that the changes are duplicated exactly across versions; only that there are changes in the same files across versions.
• The workflow does not fail if suggested changes are identified. Because there's not 100% certainty that changes were forgotten in another version, I don't want to make it look like something is broken in the PR.
• If a comment is added to a PR for suggested changes, that comment is updated as the PR changes. When all suggested changes are implemented, the comment is updated to basically say "LGTM!".
• If there are no changes missed across versions in a PR from the start, no comment is ever added.
• I initially implemented the logic for the workflow with Bash code. As I started to think about maintenance and extending my logic to support more suggestions, I got sick to my stomach. So I rewrote the main logic in JavaScript, including some unit tests for identifying the missing changes.

When should this change go live?

• This change is not yet live and should not be merged until {ADD_DATE} (apply hold label or convert to draft PR)?
• There is no urgency with this change.
• This change or page is part of a marketing blog, conference talk, or something else on a schedule.
• This functionality is already available but undocumented.
• This is a bug fix or security concern.

PR Checklist

• I have added changes to the relevant /versioned_docs directory, or they are not for an already released version.
• I have added changes to the main /docs directory (aka /next/), or they are not for future versions.
• My changes require an Engineering review, and I've assigned an engineering manager or tech lead as a reviewer, or my changes do not require an Engineering review.
• My changes require a technical writer review, and I've assigned @christinaausley as a reviewer, or my changes do not require a technical writer review.

[jonathanlukas]

This will be very helpful!