As discussed on #18470, in some cases we use default bridges
when we could avoid it.

When we succeed to connect with default bridges, we don't save
them to tca.conf, but we do save other connection settings there,
so tca.conf is not empty.

This will help validate the move of transient (UI) data to a new,
dedicated file, while from now on, tca.conf will only store
known-working Tor configuration.

#5461 (comment 173293)

refs #5461

TCA will connect automatically, so trying to run the step actually
leads to a failure. @boyska, this is intentional, right?

This scenario currently fails due to #18336, which this is a
regression test against.

Sometimes tor would succeed with the first attempt right after
unblocking the bridges, so Tor already had bootstrapped when we start
our second attempt, thus failing the test.

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.

The step "the Tor Launcher uses all expected TBB shared libraries" step has
never failed on Jenkins in the last 2 months. But these scenarios
have failed a number of time due to "Tor is ready" failing, which I assume
is because of time sync' problems.

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/

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

We are in the process of using Chutney to set up all bridges we are
going to use ourselves, so let's KISS a bit and settle with testing:

1. Old-school bridges, since they are easy to set up (all you need is
   Tor itself), still defeats simple censorship (e.g. when the Tor
   network is blocked by IP, and no DPI is involved) and chutney has a
   template for them any way.

2. The recommended and latest and greatest pluggable transports, which
   at the moment is obfs4 in Tails. Chutney does not have any
   templates for any pluggable transports, so we'll have to cook them
   up ourselves.

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)

A previous commit supposedly implemented this, but it was an old
version adapted for a different (dropped) configuration system, and
who should have been rewritten. Some complex merges and conflict
resolutions has happened since then, so a rebase would be too costly.

This is in prusuit of #6305.