Meta: Update `release-process.md` to match the new workflow based on GitHub Merge Queue

[rami3l]

Problem you are trying to solve

In the past we have used a release process based on git merge. However, with the inclusion of GHMQ, this is no longer possible. Thus, the instructions regarding cutting a new release should be updated accordingly.

Solution you'd like

Add/change a few points in the release process to match the current situation, notably:

• Use git checkout stable && git merge --ff-only master to update the stable branch, which should always contain a subset of master's commit history.
• Update the commit shasum in rustup-init.sh not in the release PR, but in a dedicated consequent PR right before tagging.
  • This commit shasum is the one right before the release. When we were using git merge it used to point to the exact commit bumping the version in Cargo.lock, but since the master history is linear now (meaning a new version will appear earlier on master than on stable, which is indeed the case for many other projects), it should be clearer if we point it to the commit finalizing the CHANGELOG instead (cf. 1.27.0 release planning #3501 (comment)).
• Tag the release onto the latest stable commit.
• How beta-testing works in Rustup via the dev environment, and when exactly to inform t-release.

Notes

Closes #3501.

[brettearle]

Happy to help here if I can?

[rami3l]

Happy to help here if I can?

@brettearle The team is currently focusing on shipping a new release and thus we are still experimenting and don't yet know what to change precisely. I'll handle this issue myself when we're done with release 1.27. Many thanks anyway! 🙇

PS: Thanks again for the other PRs you've made recently! I plan to merge them after 1.27 as well, please stay tuned!