Release tooling: Bug when making a release after a non-bump release PR has been merged

[yannbf]

Describe the bug

In our latest attempt to make a hotfix, we experienced an issue where a PR for a new hotfix release was not created.

To explain this better, we need to take a few steps back to what happened in a previous release. @kasperpeulen could give more context, but I believe what happened was:

1. A prerelease was made, which included fixes/features + build (non-bumping) changes. Therefore, there was a version bump for the prerelease.
2. Those build changes were important to patch back to main, but not the fixes/features. As a result, the "patch release" PR did not bump anything. That PR had a "freeze" label and generated a branch called version-patch-from-7.3.1. Upon merging, the version-patch-from-7.3.1 branch got deleted.

Later on (today), we had an incident that needed a hotfix, therefore the GH action to generate a patch PR executed, however the GH action was cancelled because it found a connecting PR, which had a "freeze" label in it. However that pr "had nothing to do" with the work we did.

What I believe happened, was that the GH action recreated a version-patch-from-7.3.1 branch, which shared the same head commit as the one in the previous "no bump patch release" PR. The scripts which retrieve GH PRs to check whether they're frozen or not, ended up identifying the already closed PR, which has a freeze label, and therefore bailed.

To work around this issue, we pushed a new commit to main with a minor change in a README file, and upon rerunning the GH action, the script did not find a connecting PR anymore, and therefore created a new PR. We then were able to make a release.

---

To sum up, it seems like there is a bug in the scripts, so that if we ever merge a "non-bump" (build only or docs only) patch PR, the next time we actually need to make a bumping patch PR, it will end up finding a wrong PR and bail because that wrong PR might have a freeze label in it.