docs: repair v0.35.0 release notes and automate release notes validation and rotation

[starius]

Fixed v0.35.0 release notes and added a script which manages release notes.

scripts/release-notes.py rotate <tag> <highlights> - moves release-notes-next.md into a new versioned release notes file and updates cross-references. <highlights> is a short text describing this release, which is written to the table in docs/release-notes/README.md

scripts/release-notes.py pr <base-sha> <head-sha> run per-PR checks. If it is a regular PR, it checks that release-notes-next.md is updated (unless no-changelog label is set). For a release PR (version bump) it checks that release-notes-next.md is blank and the versioned release notes file exists (i.e. the rotation has been done). This command is called by CI.

scripts/release-notes.py release <tag> checks that release-notes-next.md is blank and the versioned release notes file exists. I.e. the same check that scripts/release-notes.py pr does for a version bump PR. This command is called by release building scripts (make docker-release tag=<tag-of-release> or ./release.sh <tag-of-release>). To disable, pass SKIP_RELEASE_NOTES_CHECK=1 env var.

The workflow to make a release is:

1. Bump version.go.
2. Run rotation using the planned tag.
3. Commit both and open the PR.
4. CI checks the versioned notes file and empty next file without requiring the tag.
5. After merging, create the signed tag on that commit.
6. release.sh verifies that the tag exists, points at HEAD, is signed, and matches the compiled version; and it checks again the versioned notes file and empty next file.

Pull Request Checklist

• Add an entry to docs/release-notes/release-notes-next.md, or apply the
  no-changelog label (required by CI)

[hieblmi]

@alexbosworth for acking the new release procedure

[hieblmi]

There seems to be a problem with non-merged PRs being wrongly taken into account for a release:

Example:
1. A feature PR branches from master when the version is 0.35.
2. Later, master is bumped to 0.36.
3. The feature PR still contains 0.35, although it never changed version.go.
4. CI compares master (0.36) with the PR (0.35) and mistakenly treats the feature PR as a release PR.

The check should compare the PR with its merge base, where both versions are 0.35.

[alexbosworth]

i think we should keep it simple on the release side, but could put more complexity in the release script itself in order to avoid mistakes