ci(release-automation): make release issuance atomic

Depends on #1951

Description

As a maintainer I want to be able to issue releases without hassle so that I can spend more time doing other maintainer chores.

Currently we have scripts that automate the release issuance, but the way it works right now is that you run the script locally on your machine and then issue a PR with the administrative changes registering the release (like the version numbers being bumped in the package.json files, generating the CHANGELOG entries, etc).

The problem with this is that you tag your release commit when you make it and at the same time the npm packages get automatically published as well. So lots of automation and convenience already, but there’s a concurrency issue at play which already manifested itself with our 0.2.0 release: If someone gets between your release PR and your release commit, then your tag will actually diverge, which is not a huge issue, but it could become confusing/annoying/even problematic once we get to GA and start doing hotfixes, backports on older release branches regularly (an unfortunate chore of mature software maintenance).

So, I had this idea (that I actually just stole from Besu, while I was browsing their CI code for something totally unrelated) that what we need is a separate github action (workflow yaml file in the .github directory) that will run only on branches matching the pattern of release-* and this workflow will run the publish script that uploads the package contents to npm (and later on all the other things that we want to publish such as Java jars to BinTray/Maven Central for the Java bindings to the Cactus API). With this change, the release workflow would become this:

1. Run release script locally on your machine, send a PR
2. Have everyone agree on the release (e.g. approval)
3. Merge the PR
4. Tag the commit you just merged
5. Create a branch called release-$SEMANTIC_VERSION
6. Push the branch to the upstream (e.g. Hyperledger/Cactus)
7. Sit back and watch the CI publish your artifacts (because it got triggered by the branch name matching the pattern mentioned above).

Acceptance Criteria

1. Possibility of diverging the release tag from the main branch is eliminated
2. npm packages are automatically published and before the container images are published (sequential order for them must be guaranteed)

cc: @takeutak @sfuji822 @hartm @jonathan-m-hamilton @AzaharaC @jordigiam @kikoncuo @petermetz @arnab-roy @jagpreetsinghsasan

[petermetz]

@petermetz I’ve installed it, but I’m not sure what more I need to do. If it needs more config, let me know?

@ryjones It worked! Now I have a tool to keep the release issuance atomic, happy days!

[petermetz]

@ryjones I found this GH app called “MergeFreeze” which is meant to help out with situations like ours where PRs that are about issuing releases need to halt all other PRs until they are merged to keep the generated change logs and build artifacts consistent. Any chance that you could enable it for the HL GH org? It is free for open source projects so I’m hoping this is not something Hyperledger would get charged for at all (entirely different conversation if that’s not the case though).

MergeFreeze: https://github.com/marketplace/merge-freeze/plan/MDIyOk1hcmtldHBsYWNlTGlzdGluZ1BsYW4yMjAy#pricing-and-setup