Some distros don't have GNOME Disks well integrated or some non-Debian
users might still prefer the command line.

The follow-up fixes after the review of this branch were pushed
but not reviewed yet. Regardless, we need this branch merged
so that 3.12~rc1 can be prepared.

refs: #15999

This branch might be incomplete (left to check) and it needs a tiny bit of
polishing, but it's definitely an incremental improvement over the current
state of things: this will ensure we have a more relevant test suite
when preparing 3.12~rc1.

refs: #16004

(Fix-committed: #16352, #16184)

I want a search'n'replace feature that also updates grammar accordingly.
M-x what?

I wrote the initial draft before the corresponding code actually existed.
In the end we decided to guess the filename of the .img based on the filename of
the .iso and thus we did not add a --old-img flag.

Merge remote-tracking branch 'origin/doc/15999-integrate-usb-image-in-the-release-process' into doc/15999-integrate-usb-image-in-the-release-process

Test suite: when MAC spoofing fails, test safety-critical properties even if the notification is not displayed.

As said on #10774, it's not clear to me whether these scenarios'
frequent failure is "merely" (sic) a test suite robustness issue,
or an actual bug in Tails.

But anyway, MAC spoofing fails, what matters above all is that the network
interfaces are disabled and that the real MAC address is not leaked, so let's
test this first: this way, even if there's a problem wrt. displaying the
notification or wrt. the test suite catching it, by running these scenarios we
will at least ensure the user is safe — possibly with poor UX, but safe.

refs: #10774

Let's align with the updated documentation: those scenarios aren't
documented any more, drop them entirely.

It's way quicker to copy the old version of Tails using its USB image
instead of starting it from DVD and cloning to USB.

Use the implementation of the usb-install-tails-greeter checkpoint, with
a few variations (old Tails USB image, and different device name).

Also, instead of removing the USB device at the end, trigger a proper
shutdown of the computer (the emergency shutdown would be triggered
anyway).

These scenarios are taking the expected shortcut (installing from the Tails
USB image directy), due to the following chain of parent checkpoints:
 - usb-install-with-persistence-logged-in
 - usb-install-with-persistence-tails-greeter
 - usb-install-logged-in
 - usb-install-tails-greeter

Let's optimize the test suite by installing the Tails USB image directly,
instead of doing the cloning dance. Remove the parent snapshot accordingly,
as there's no need to be running Tails in the first place anymore.

The Tails USB image could be trusted not to have any persistence
partition but let's keep that check anyway; that's part of a checkpoint.

The (absence of) persistence check used to appear twice; get rid of the
first instance as that one was performed after cloning, with a computer
that was still running. Keep the second one only, which happens after
the just installed system has booted.

dkg has updated his key so the previous image does not match anymore.

Merge branch 'feature/16072-protected-regular-and-fifo-files+force-all-tests' into bugfix/16352-16184-systemd-v240+force-all-tests

Merge branch 'bugfix/16097-memory-erasure-on-shutdown' into bugfix/16352-16184-systemd-v240+force-all-tests

Merge branch 'bugfix/16349-tor-0.3.4+force-all-tests' into bugfix/16352-16184-systemd-v240+force-all-tests

Let APT install the newest systemd among those available in stretch-backports and in our custom APT repo (refs: #16352, #16184)

This ensures our custom backport (240-4~bpo9+0tails1) is superseded
by the official one once the latter is uploaded.

Mount a dedicated tmpfs on /run/initramfs instead of trying to remount /run with the "exec" option (refs: #16097).

My previous approach, i.e. "let's remount /run with the exec option via a unit
file started as part of the shutdown procedure", worked just fine for clean
shutdown. But it does not work for emergency shutdown, i.e. when the boot medium
is physically removed: for some reason (possibly missing bits in the memlockd
configuration), this service is not started, and then systemd-shutdown won't
return to the initramfs because /run/initramfs/shutdown is not executable.

So let's instead disregard /run and extract the initramfs into a dedicated
tmpfs, that we mount on /run/initramfs (where systemd-shutdown will look for
it), and that we mount without the "noexec" option.

Also, remove manual calls to eject(1):

 - They increase chances that the shutdown process breaks due to missing
   files locked in memory by memlockd.

 - Their sole benefit is to ensure we physically eject the DVD. It's unclear if
   this code is still needed nowadays. Regardless, starting with Tails 3.12, the
   only supported use case for ISO and DVD is virtual machines, which are not
   targeted by the emergency shutdown feature, which is about removing the
   *physical* boot medium.

Merge branch 'feature/16073-linux-4.19+force-all-tests' into feature/16072-protected-regular-and-fifo-files+force-all-tests