ci: skip reverted commits in release notes, publish tagged snaps to stable (#39657) (#39678)

Backport #39657 by @bircni

Release notes: revert commits and the commits they revert are now left
out of the git-cliff changelog. A step before git-cliff finds commits
whose subject starts with "revert", reads the PR numbers on their revert
lines, and writes both SHAs to `.cliffignore`.

Snap: since the move from Launchpad to GitHub Actions, every build was
uploaded to `latest/edge`, including the stable-grade build that
`part-gitea-pull.sh` makes for an unreleased tag. Launchpad used to
release those builds to candidate and stable automatically. Without
that, v28.0.0 had to be promoted by hand and v28.1.0 stayed in edge.
Stable-grade snaps now go to `latest/stable` and `latest/candidate`;
main builds still go to edge. Candidate has to be updated too because
the pull script compares against it.

Signed-off-by: bircni <bircni@icloud.com>
Co-authored-by: bircni <bircni@icloud.com>

snap/part-gitea-pull.sh

@@ -16,13 +16,14 @@ else
 fi
 
 # How it works:
-# * snapcraft.io checks out the default branch (e.g.: main during 1.27 dev period)
+# * release-nightly-snapcraft.yml builds the snap on every push to the default branch (e.g.: main during 1.27 dev period)
 # * "override-pull" step gets the latest tag by date (e.g.: v1.26.1)
-# * use "snap info gitea" to get the latest released tag
-#   * if the latest tag is not released to stable, checkout that tag and build it for "stable"
-#   * otherwise, build the main branch for "devel"
+# * use "snap info gitea" to get the latest released tag, which is the version in the "latest/candidate" channel
+#   * if the latest tag is not released yet, checkout that tag and build it with grade "stable",
+#     the workflow publishes it to "latest/stable" and "latest/candidate"
+#   * otherwise, build the main branch with grade "devel", the workflow publishes it to "latest/edge"
 # * "override-build" step uses build script from the checked out commit to build
-# This approach highly depends on the "main" branch's push.
+# This approach highly depends on the "main" branch's push: a new tag is only published by the next push after it.
 
 # To debug the logic:
 # * last_committed_tag=v1.26.1 last_released_tag=v1.26.0 ./snap/part-gitea-pull.sh