In particular this enables the retry magic we added for the "Tails
documentation" launcher to the "Report and Error" case since the code
now is refactored and used in all cases.

We won't have it in Tails 3.0~beta1 since the Greeter doesn't have
that option, and it's not even sure we'll reintroduce it since it's
apparently quite buggy and not widely used.

Will-fix: #12055
Refs: #12093

Unmark as fragile one more test case that was disabled due to "11a7a9a4" being fragile (refs: #10381).

It was initially disabled in commit:5d797fea.

The TailsOfflineDocHomepage.png image doesn't match what we see any
more (I have no clue why), so let's use Dogtail and solve this once
and for all, hopefully.

This might be needed to give Tor Browser enough time to start.

One step to rule them all!

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

Refs: #11592

Refs: #11591

This reverts commit 47d9d43f.

refs: #11590

This reverts commit 08c08e67.

With more than 1 core in the tester VM, WebM is no longer broken in
Tails, so the test can be enabled again.

Refs: #6729, #11507

... but only on a single core system, which is what we happen to use
in our automated test suite VM at the moment.

Refs: #11507, #6729

This might improve reliability somewhat. At least we depend on one
less host being up (we already depend on our website).

Refs: #10442

This step was broken due to Tor Browser 6.0.x changing the zoom-levels
(or similar) so various elements of the just removed image were not
positioned the way we expected them.

It doesn't make sense now when we use Chutney since that always means
it will report that Tor is not being used.

In some scenarios we used it simply because we needed *some* page
(distinct from the Tails News page) and we had the image. In those
cases we now use the Tails homepage instead. I tried to use dogtail,
but realized that dogtail won't work for the Unsafe Browser due to

... after logging in via Tails Greeter. Now we do some very important
stuff there, like enabling the accessibility toolkit in GNOME. That is
specifically something we lose if we forgot to run that step after
rebooting, which specifically was a problem in at least one scenario
(Deleting a Tails persistent partition).

While we're at it, let's also run the 'Tails Greeter has dealt with
the sudo password' step at the same time.

The old design was very inflexible, which over time lead to the
implementation growing messy as different checks were added. The
issue was that it had to hard-code the particular checks we
wanted, and did not allow the user to formulate an expression for
which packets are considered leaks or not. So, let's instead
provide an assertion-like function to which the user passes a
block describing how we want all our packets to look.

Furthermore, now all firewall leak tests should be ok with the
simulated Tor network provided by Chutney. Since all Tor nodes
(incl. bridges) run from the same host (and IP address) we also
include the server port when verifying that no unexpected hosts were
contacted.

Note that in some cases we've lost a bit of information and
precision, e.g. among the anti-tests we no longer exactly match
the protocol that was leaked, but that wasn't very valuable to
begin with, and instead we test *exactly* the code that these are
anti tests for -- a true anti test, indeed!

Also, the 'no traffic has flowed to the LAN' (now renamed) had a
serious bug which was fixed in passing -- the `@lan_host`
variable was not set, so it is `nil`, which could never be among
the IPv4 TCP leaks, so that step always succeeded! :S

In this case, a Tor Check failure is expected.

This reverts commit f8e5fb99.

Since #9285 was solved we do not allow opening downloaded files with
external applications in the Tor Browser.

Refs: #9285

Per the discussion on ticket #9285 we should exchange the scenario
that tries to open a downloaded file in an external application (which
we now do not allow) with a scenario where we just downloads a file.

Refs: #9285

This reverts commit 0163c64d.

Refs: #10720

They all rely on the `wait_until_tor_is_working` helper which has lately
proven to be still buggy. That's tracked by ticket #10497.

Will-fix: #10706

This reverts commit 5d797fea.

This reverts commit 1e5fd8f8.

Essentially I did:

    sed -i 's/Tails has booted/I have started Tails/' -- \
        features/*.feature features/step_definitions/snapshots.rb

(although there was a false positive that I had to restore)

Most of the time when testing persistence, this is what we need so it
will save some time and make the scenarios simpler.

The basic idea is to first run a "I start monitoring the AppArmor log"
step, which records the current time, and that any "AppArmor has
denied" step run for the same profile later will only look at entries
from that time and on. The wordings on the steps now make the
scenarios a bit clearer, and we also don't have to clear syslog any
more as an ugly workaround.

Furthermore, this will bring us close to a clean solution of #9924,
which will require us to run a sysctl command *before* anything that
could generate the AppArmor log entries we're interested in. The "I
monitor" step is a perfect candidate for that, wereas we before would
need yet another step.

Due to the alias, /live/overlay will be treated as
/lib/live/mount/overlay.