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.

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

This is about verifying that the upgrade was correctly applied,
not about the Unsafe Browser.

This brings back 2763439d:
https://redmine.tails.boum.org/code/issues/15286#note-8

Currently translated at 17.7% (11 of 62 strings)

Translation: Tails/wiki/src/news/version_3.14.1.*.po
Translate-URL: http://translate.tails.boum.org/projects/tails/wikisrcnewsversion_3141po/pt/

Currently translated at 39.0% (16 of 41 strings)

Translation: Tails/wiki/src/news/version_3.11.*.po
Translate-URL: http://translate.tails.boum.org/projects/tails/wikisrcnewsversion_311po/it/

Let's restore the previous behaviour, which is unplugging the USB drive
at the end of the scenario. That might not be entirely needed, but
better safe than sorry.

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

Refs: #14576

Refs: #14596

No work on the steps have been done so far.

Refs: #15286

This just feels like better organization!

Now that the splash screen is gone, this scenarios happen in the exact
same context as its "Install by cloning" version in
usb_install.feature.

Refs: #8859

Now that the splash screen is gone, these scenarios happen in the
exact same context as their "Upgrade by cloning" version.

Refs: #8859

Refs: #8859, #8860

In the real world, USB sticks labeled "8 GB" can be much smaller,
so Tails Installer will accept anything that's at least 7200 MiB.

This commit makes us exercise something closer to what happens in the real
world, and incidentally it'll save storage space on our isotesters
and improve test suite performance a bit :)

Test suite: take into account that Tails Installer will soon refuse installing Tails to devices smaller than 8 GiB (refs: #12707).

It'll still allow *upgrading* such sticks though.

Beside the image bumping due to the new font we use in Stretch, we
also take steps making Tor bootstrap more reliable in the upgraded
system. It used to be unreliable because the IUK sets a very wrong
release date, and we use it in our time syncing.

So now we can use snapshots in the affected scenarios, which this commit
also implements.

Will-fix: #5571

The retry-logic we add makes some steps awkward, especially when they
really are about verifying the results of some previous steps. Any way,
let's make the best out of it.

bugfix/11590-installer-robustness was based on this branch
(bugfix/10720-installer-freezes-on-jenkins), and flagged the tests as
fragile again, so we have to revert that on this branch so these tests
run on Jenkins again.

refs: #10720

This reverts the following commits:

  3c02ea74
  20d07239
  2c4c6434

This reverts commit 47d9d43f.

refs: #11590