Requiring to `set -u` in the terminal won't really work since that will
break e.g. bash completion.

    sed -i 's,\${\([A-Za-z_]\+\)},${\1:?},g' \
        wiki/src/contribute/release_process.mdwn

    sed -i 's,\$\([A-Za-z_]\+\),${\1},g' \
        wiki/src/contribute/release_process.mdwn

Rationale: the translation work is not moving very fast these days,
being quite polished for many languages, so we gain very little from
frequently pulling it and preparing releases *only* for new translations
(no new code). So, let's relieve the RM from this work for most
releases, but still have a process in place for making sure that
translations are pulled regularly.

Will-fix: #11860

Refs: #11851

Let's always encode, on the stable branch, the exact set of APT snapshots we
want to use in next point-release. Previously we would pretend to thaw them by
writing "latest" in APT_snapshots.d/*/serial, but then apt-mirror would
special-case this situation: on an unreleased branch based on stable, it would
consider that "latest" means "stick to previous release's tagged snapshot".
Which worked fine at build time, except the part of our build system that
creates the build manifest does not know about this convention, so the resulting
build manifest would point to the latest APT snapshots we have, even though they
were not really used during the build. And even if the build manifest pointed to
the right place (i.e. the previous release's tagged APT snapshot), which is the
only place where some of the needed packages are when tagging the next
point-release's APT snapshot: tails-prepare-tagged-apt-snapshot-import does not
know how to generate a configuration that pulls from there.

So let's drop this special meaning of "latest", and make things simpler by
actually hard-coding in Git the snapshots we really want to use.

This implies the documentation change that makes sure that we're keeping these
time-based APT snapshots long enough.

refs: #11612

This reverts commit 3e9f477b.

This reverts commit 33c265db.

We haven't been handling broken tests like that for at least 1.5 years.

$status is a shell read-only variable there.

Release process: take into account that most manual testers don't have access to our Gobby ⇒ we're using pads these days.

At this point we're still working on the $RELEASE_BRANCH. We'll be
merging into master later, as documented.

It was too easy to miss that comment.

The goal here is to point translators to up-to-date PO files,
which can only work if we actually publish the updated ones.

I'm not sure if we've ever used it. In any case, nowadays we simply
update the design doc on the corresponding topic branch, so there's no
need to maintain documentation about the future on the live version of
our website (master branch).

tails-iuk-check-upgrade-description-file assumes the existence of a
valid signature.

This way we only check the correctness of *new* UDF:s, and not old one
that might be correct, but have signatures made with an expired key
which otherwise report useless errors.

The old instructions will lead to *all* UDF:s (even unmodified ones)
having their signature remade, which is unnecessary.