ci: Ensure all version references are up-to-date prior to release

[pnacht]

Closes #370. Please look carefully, the workflow introduced here works on PRs, so make sure it doesn't allow untrusted content to be interpreted.

This PR adds a new pre-release check: in PRs with #[]label:release (adding dummy brackets not to trigger anything!) in the description, ensures that all version references are up-to-date. These include:

• the major version declared in the first line of go.mod;
• the most recent version declared in the first line of SHA256SUM.md (in both the link and the text);
• all references to slsa-verifier in the README.md.

Should any inconsistencies be found, the logs will display them, for example:

SHA256SUM.md and go.mod have different major versions:
go.mod:       v3
SHA256SUM.md: v2 (v2.0.1)

SHA256SUM.md: Visible text and linked URL do not match:
### [v2.0.1](https://github.com/slsa-framework/slsa-verifier/releases/tag/v2.0.2)
      ^^^^^                                                                ^^^^^ 

README.md and SHA256SUM.md refer to different versions:
SHA256SUM.md: v2.0.2
README.md:
  133:$ cd slsa-verifier && git checkout v2.0.1
  139:Download the binary from the latest release at [https://github.com/slsa-framework/slsa-verifier/releases/tag/v2.0.1
  139:](https://github.com/slsa-framework/slsa-verifier/releases/tag/v2.0.1

The logic for the README is brittle, relying on the fact that all current version references there are prefixed by the string slsa-verifier. Should this change in the future, the logic may need to change.

Also, this logic currently runs on all PRs marked with #[]label:release. Should release-candidate PRs be omitted?

[ianlewis]

Suggested change

	###
	### SHA256SUM.md
	###
	read -r line < SHA256SUM.md
	# Read the top line of SHA256SUM.md
	read -r line < SHA256SUM.md

[pnacht]

An issue: I just noticed that I can't find any PRs that adopt the #label:release description. Is this actually used in this project or should I change the logic somehow?

[laurentsimon]

An issue: I just noticed that I can't find any PRs that adopt the #label:release description. Is this actually used in this project or should I change the logic somehow?

We might not have released a verifier version yet with it, I don't remember.
Here's one example on the generator slsa-framework/slsa-github-generator#1498

[ianlewis]

An issue: I just noticed that I can't find any PRs that adopt the #label:release description. Is this actually used in this project or should I change the logic somehow?

We might not have released a verifier version yet with it, I don't remember. Here's one example on the generator slsa-framework/slsa-github-generator#1498

Right, we may want to add it to the RELEASE.md docs as well if it's needed.

[pnacht]

I've just pushed a commit adding that instruction to RELEASE.md. I'm actually going to make a change to the script to take advantage of the fact that the version is actually declared in the #label:release X.Y.Z.

[asraa]

This looks great!

One qq -- can you fix DCO? (Or maybe TBH we should just remove it..)

[pnacht]

Ops, hadn't noticed the DCO. Fixed. I also just submitted a new commit to use the #label:release v1.2.3 in the PR description as the source-of-truth for the release version.

[ianlewis]

This looks great!

One qq -- can you fix DCO? (Or maybe TBH we should just remove it..)

We may need to require it at some point (right now it's non-blocking). The slsa repo requires it for example.