As per https://metacpan.org/pod/LWP::UserAgent#request,

  Note that errors writing to the content file (for example due to permission
  denied or the filesystem being full) will be reported via the Client-Aborted
  or X-Died response headers, and not the is_success method.

We were already handling X-Died specially, but not Client-Aborted,
so there could be cases when we later treated the download as failed
(due to size or hash mismatch) but did not report about the origin
of the problem, which would make debugging of user bug reports harder.

Give more hints wrt. the impact.

This section was too big for my taste. In any case, it covered
more than what its title indicated.

This is a follow-up on a9fa544b:
the same reasons apply here too.

This problem has not happened since a few years, mostly because I'm now aware of
it and thus careful. Moreover, we now have a build_IUKs Jenkins job, that takes
a TAILS_GIT_COMMIT parameter, and can thus be used to test new IUK generation
code before it's merged and affects a RM, on real-world scenarios. I'm using
this regularly when working on the IUK codebase. As it happens, this job runs on
Jenkins' isobuilders, that currently run Stretch.

So all things considered, I'm now confident that this note does more
harm (scaring the RM) than good (providing useful and actionable information).

Release process: adapt garbage collection of IUKs to the single SquashFS diff upgrade scheme (#15284)

In the single SquashFS diff upgrade scheme, we'll generate and publish many more
IUKs and will need to delete obsolete ones more aggressively. The good news is
that we have a much better criterion for that than the age of an IUK: since
every new release will have IUKs that upgrade to this new release from any older
version that has the same "X" as the new release in "version X.Y", we know
it follows that any IUK that upgrades to anything but the version that
was just released is obsolete and can go away.

So essentially, at any point in time, our mirrors will store the set of IUKs
that upgrade to the current version of Tails, and that's it. The only exceptions
are:

 - IUKs v1, that we'll need to garbage collect manually at a well chosen time;
   this is a one-time cleanup operation and does not seem worth automating;

 - In the release process, between the time the IUKs for the new release
   are uploaded, and the time when the RM goes this this post-release
   cleanup step, our mirrors will store 2 sets of IUKs: those that upgrade
   to the previous version, and those that upgrade to the new one.

At least in theory, there can very well be, for example, both IUKs v1 and v2
that upgrade from 4.1 to 4.3 and have the same filename. The difference
will be the meaning of "from 4.1" and the content.

Let's avoid having to deal with that.

Fixes test suite regression introduced
in cced26b6.

tails-create-iuk previously left temporary files behind. In particular, even on
success, the "squashfs_src" directory would remain on the filesystem.

It's no big deal in general, but our build_IUKs Jenkins job runs
tails-create-iuk as root with sudo, so the leftover temporary files are owned by
root, and then the "workspace-cleanup" step (itself run as the "jenkins" user)
can't delete them, which causes 2 problems:

 - These temporary files would endlessly accumulate on isobuilders,
   without any mechanism to clean them up automatically.

 - Confusing output in the Jenkins console:

      cannot remove path when cwd is /var/lib/jenkins/workspace/build_IUKs/j4gMvgS3wH for /var/lib/jenkins/workspace/build_IUKs/j4gMvgS3wH:  at /usr/share/perl/5.24/File/Temp.pm line 1583.
      Archiving artifacts
      [WS-CLEANUP] Deleting project workspace...
      Cannot delete workspace: null
      Option not to fail the build is turned on, so let's continue

On our Stretch isobuilders, passing --xattrs to rsync when generating an
aufs-based IUK makes it fail: setting xattrs on a file in an aufs filesystem
raises an "operation not supported" error.

We only need to preserve xattrs when building overlayfs-based IUKs,
because aufs will lose them at mount time anyway.

I've seen cases when the ESC key stroke in "all notifications have disappeared"
closes the very dialog that we'll be looking for in the next step
("I am proposed to install an incremental upgrade to…"). I suspect
this never happened before because the Upgrader took longer to start,
so optimizing it introduced this race condition.

In these scenarios, I doubt that closing notifications is important: the
aforementioned zenity dialog is always displayed in the center of the screen and
there's little change a notification hides it.

The Unsafe Browser needs a DNS resolver configured so we need to plug
the network first.

While working on the test suite, it took me a while to figure out why the exit
code, stdout, and stderr of a failed command was not in the Journal. It turns
out that it's because our test suite does not properly close the zenity dialog
that we display before printing the more detailed debugging info to STDERR and
thus to the Journal, which makes debugging via the test suite impractical.

A user could be affected in a similar way: before this commit, when we told them
"For debugging information, execute the following command: sudo
tails-debugging-info", the info we were referring was actually not in the
Journal yet.

Given the test UDFs we're using, an initially installed 2.0~test
will be upgraded to 2.2~test.

Move the Upgrader's trusted keyring to tails-upgrade-frontend's $HOME and make it writable by that user (refs: #15279)

This will be needed in order to refresh our signing key before checking
for upgrades.

generate-languages-list is not meant to be used directly
by anyone, so let's move it out of the way.
auto/build has auto/scripts/ in its $PATH.

tails-iuk-check-upgrade-description-file uses Data::Dumper::Concise.

The RM also needs them.