[release process]: Do release candidates

[ArthurSens]

We're getting to our fifth patch release for client_golang 1.20 at #1645. We even had patch releases with 3 days differences between 1.20.1 and 1.20.2, and even two separate patch releases for data races in native histograms that were discovered with a tiny time window between them.

Those issues could easily have been caught with release candidates that people could test before we commit to a stable release. The proposal here is to do exactly that: Update our release process with release candidates :)

[bwplotka]

First question, what's wrong with multiple patch releases? Having multiple patches, especially as many have upgrades automated, might be not that bad.

Second, who will commit the time to try rc release? 🙃 For non-rc it's a dependabot proposing PR and highlighting issues.
In my experience, especially with libraries, not many will voluntarily try rc version, unless there is a interesting feature to get early. Perhaps we could propose Prometheus will consume rc releases automatically, if Prometheus team approves that flow.

Nevertheless, we can try and see if there's any effect!

[bwplotka]

Similar, but non-conflicting idea #1648

[stale]

Hello 👋 Looks like there was no activity on this issue for the last 3 months. Do you mind updating us on the status? Is this still reproducible or needed? If yes, just comment on this PR or push a commit. Thanks! 🤗
If there will be no activity in the next 4 weeks, this issue will be closed (we can always reopen an issue if we need!).