support minor release create test plan workflow

[aelnahas]

Motivation/summary

This PR will allow us to automate the test plan creation for minor releases

Changes that were done:

• update the generate-test-plan.sh to now handle minor releases
• update the documentation
• renamed create-test-plan-patch to create-test-plan to avoid confusion now that it handles both minor and patch releases
• update documentation

Checklist

• Update CHANGELOG.asciidoc
• Documentation has been updated

For functional changes, consider:

• Is it observable through the addition of either logging or metrics?
• Is its use being published in telemetry to enable product improvement?
• Have system tests been added to avoid regression?

How to test these changes

# since the workflow name has been releases I invoked the script from my terminal e.g.

➜  via 🐹 v1.26.2 bash .ci/scripts/generate-test-plan.sh 9.4.0
Upcoming release: v9.4.0
Release branch: 9.4
Previous tag: v9.3.3
Commits analyzed: 165
Generated build/test-plan-9.4.0.md

# then checked the output by 
cat build/test-plan-9.4.0.md


# did this for the following versions:
# 9.4.0 <- minor 
# 9.3.4 <- patch
# 9.0.0 <- when minor version is zero it should error out
# 9.6.0 <- when no tags exist for 9.5.* then it will error out as well

for convenience here are the test plans that were created by invoking this script:

• 9.3.4: [Test] 9.3.4 Test Plan aelnahas/apm-server#3
• 9.4.0: [Test] 9.4.0 Test Plan aelnahas/apm-server#2
  they werent created by the workflow rather I ran the script and pasted the output test plan as an issue to my fork.

Related issues

#20454

[mergify]

This pull request does not have a backport label. Could you fix it @aelnahas? 🙏
To fixup this pull request, you need to add the backport labels for the needed
branches, such as:

• backport-8.19 is the label to automatically backport to the 8.19 branch.
• backport-9./d is the label to automatically backport to the 9./d branch. /d is the digit.
• backport-active-all is the label that automatically backports to all active branches.
• backport-active-9 is the label that automatically backports to all active minor branches for the 9 major.

[github-actions]

🤖 GitHub comments

Just comment with:

• run docs-build : Re-trigger the docs validation. (use unformatted text in the comment!)

[carsonip]

a way to test this would be to reuse the same workflow name, push it to a branch under elastic/apm-server, i.e. not your fork, then you can run it on GH actions. Only after testing you may rename it as you like. This is because GH requires a workflow to be on main for it to be shown on the UI.

In this case, since the workflow doesn't do much other than invoking the script and creating the issue, you may decide if the local validation is enough.

I'll do a review separately

[aelnahas]

#20969 (review)

Worth doing just to make sure the renaming doesnt cause issues

[carsonip]

q on base tag decision logic. Since you already spent some time on it you might have a convincing answer ready

[carsonip]

I'm not sure if the base tag detection logic is 100% correct. And at the very least it should not depend on when the generate test plan script is run. It is not a simple question though, under the existing 2 active minors model - how do you decide if a change should show up in minor changelog, e.g. 9.4.0?

• Obviously, if a change is merged to 9.4 (either before or after FF) but not 9.3, it should be in 9.4.0 changelog
• But what if a bugfix is merged and due to be released in both 9.3.x and 9.4.0?