We're testing that the bug exists and that setting the time fixes this.

we change the time ourselves, to simulate what TCA should have done.
that's just to run the whole scenario, but clearly doesn't test anything
about the actual implementation in TCA.

anonym & I went through our whole test suite and added these tags
where we thought they were deserved.

We did not look at tor_bridges.feature though, since big changes
to that feature are in the works (#18270).

refs #18103

Bridges can use PTs or not -- bridges are _not_ a type of PT.

I picked a rather transparent and implicit approach, by handing the
default Tor Launcher case (direct connection) right in the `Tor is
ready` step. This might be a bit opaque and confusing, however, but
otherwise, in all scenarios/snapshots where we have:

    And the network is plugged
    ...
    Then Tor is ready

we would have to add steps:

    And the network is plugged
    ...
    And the Tor Launcher autostarts
    When I configure a direct connection in Tor Launcher
    Then Tor is ready

which is a bit spammy. I suppose it could be compressed into:

    And the network is plugged
    ...
    Then Tor is ready after I choose a direct connection in Tor Launcher

but I don't like that kind of formulations in Gherkin.

Scenario names are supposed to concisely describe the desired behavior
of the system under test, rather than the steps required to perform
the actual tests.

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 verify whether our time sync'ing mechanism still works even without
the hack that temporarily increases tor's log level in bridge mode.

Adjust the test suite to reflect the fact we use the source date, and not the build date anymore (refs: #12339).

Refs: #11589

"tordate" just isn't working well in Tails, so we shouldn't expect the
tests to actually work all of the time. The two tests we keep will at
least ensure that "tordate" doesn't break the (presumably) most common
situation, where the hardware clock is correct.

Refs: #10440

We don't need to be fancy about the case any more.

This reverts commit f8e5fb99.

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.

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)

For users that keep their Tails up-to-date it's very reasonable that
their Tails release date can be ~six weeks ago. Since Tails will set
the clock to the release date if it detects a time earlier than that,
we should test at least this case.

There's little reason for keeping them separate, especially when
time_syncing.feature can't have a background any way (due to the
hardware clock scenarios) which otherwise might have been a tiny
motivation.

This will make things much easier when converthing to the new snapshot
model.

Thanks to

    config/chroot_local-includes/lib/live/config/0001-sane-clock

these scenarios cannot happen, and since we test that it works they
can be safely removed.

I.e. check that

    config/chroot_local-includes/lib/live/config/0001-sane-clock

does what it's supposed to, which is to ensure that the system clock
cannot be set before the Tails build date (if so, we set it to the
Tails build date).

Will-fix: #9377

Factorize common pattern into a single "I start Tails from DVD with network unplugged and I login" step.