Will-fix: #10706

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.

... because when the user-tmp abstraction is used, AppArmor doesn't
log it.

... by looking in the audit log. This way we actually know that
apparmor denied the operation, and so we don't get false positives of
some classes of errors (e.g. the file simply has wrong permission or
similar).

Since we migrated to a browser based on Firefox esr38 we no longer get
any graphical feedback for the apparmor blocking, which is the actual
reason for implementing this.

Test suite: make sure we don't find TorBrowserUnableToOpen.png *before* the page we're not supposed to be able to load was actually loaded.

In the previous state of this test, even if the forbidden page could be
"successfully" loaded, a fast enough testing system would find
TorBrowserUnableToOpen.png earlier, and then the test would pass even though it
should not.

Test suite: add a anti-test to (in)validate the 'I see "TorBrowserUnableToOpen.png" after at most 10 seconds' one.

Will-fix: #9286

It shouldn't be needed for the Tor Browser test since we check the
network traffic, but we'll need it when testing the Unsafe Browser, so
why not?

Since no HTTP server is listening on the LAN resource the Tor Browser
would show the same "Unable to connect" error message even if the
request wasn't blocked. We should be fine, though, since we check the
captured traffic. The picture is more of a signal saying that "now the
network traffic would have been generated *if* the request isn't
blocked" which we use to know when to check the network capture.

Instead of the explicit steps for capturing all traffic and checking
for leaks.

First we start the Tor Browser, then we run the step 'there is a GNOME
bookmark for the amnesiac Tor Browser directory' which opens the GNOME
Places menu. It seems this may cause the Ctrl+S key presses in the
next step 'I can save the current page as "index.html" to the default
downloads directory' to not reach the Tor Browser, but probably get
lost in the Places menu before it closes from the Esc key press
(Sikuli is fast!), so the step fails. The new step ordering prevents
this from happening.

The previous implementation fails consistently for anonym, likely because the
ENTER key event isn't bound to its callback early enough, or similar. Let's hope
the OK button isn't displayed as being ready before it really is.

WIP: Rename the Tor Browser "download" directory, again. And add automated tests for the Tor Browser.

The idea is to make sure that the AppArmor confinement doesn't break too much
functionality, and actually confines the browser a bit.

Sorry for the non-atomic commit: getting directory name changing under my feet
while the automated tests are being drafted made it too hard to split this in
a nice way.

Beyond s/Iceweasel/Tor Browser/ (incl. renaming affected images) we
also try to rely more on clicking on GUI elements instead of keyboard
shortcuts. The TBB is noticeably slower on start, and often loses key
presses at that stage, so clicking is much more reliable then.

The most remarkable change may be the switch to the step "the Tor
Browser has started and loaded the startup page". It seems a fair
amount of complexity is required to reliably stop the loading of the
startup page so this simpler approach seems better, and as a bonus it
actualy tests the startup page. The issue described in the removed
comment doesn't seem very relevant any more, too.