This reverts commit 75449088.

I need the test suite working to release 3.0~beta2, and it's been quite broken
on feature/stretch since the merge of test/12059-dogtail-optimizations.

refs: #12305

This is a fixup on 2dddaca0.

refs: #12130

But only for those applications where we expect that.

The expected outcome is expressed by the following step.

Since commit:c45a20e6 we also install netcat-openbsd, which has higher priority
in Debian's "alternatives" system, so calling "netcat" uses it. But our test
suite relies on that command's behaviour to be nc.traditional's one, so let's
use it explicitly.

connect-proxy seems barely maintained in Debian and was removed from testing due
to https://bugs.debian.org/830423.

This test was introduced (#8960) back when we relied on our hard-coded
TOR_AUTHORITIES variable being correct, for the other Tor enforcement tests.
We don't use that variable anymore, so let's not bother maintaining it.

And in turn, let's not bother porting this test to Tor 0.2.8 and fallback
directory mirrors.

refs: #11351

The "convenience aliases" were just confusing.

We're dealing with connections (which "c" is short for), not hosts.

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

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

There's really no need to first gather the bridge configurations and
then construct + write the bridge lines -- let's just do it in the
same loop.

... by removing unnecessary class variable (it's not used outside of
this step) and give the replacement (local) variable a better name.

Note that @bridge_hosts is pretty stupid at the moment, since it will
get the same static value appended many times, but improvements are
pending.

We now set up all bridges (from now on that term also includes PTs)
using Chutney, so we no longer need to provide them in our "secret"
local configuration any more, which is a big plus in itself.

This includes replacing one of the authorities with a bridge
authority.

Note: the firewall test (i.e. that only the expected hosts are
contacted) is pretty broken at the moment, definitely in the bridge
mode case, but perhaps in normal operation too, since what we check is
which hosts are contacted, and the complete Tor network *and* bridges
now run on the same host (and IP address).

We don't allow all RELATED connections anymore.

The old `iptables_parse()` way relies on regex parsing the output of
the `iptables` output, which of course is not very reliable. In Jessie
the `ip6tables` output has changed and differs (if there are no
options the "opt" column will be empty, and not have a "--"). The new
parser fixes this.

The goal will be to convert all `iptables_parse()` instances to the
new parser.

Will-fix: #9704

.. and pass -P to grep, since Ruby uses PCRE.

On Jessie, setcap is used by default instead of setuid root for /bin/ping,
but aufs does not support file capabilities:

  $ /sbin/getcap /bin/ping
  Failed to get capabilities of file `/bin/ping' (Operation not supported)

  $ /sbin/getcap /lib/live/mount/rootfs/filesystem.squashfs/bin/ping
  /lib/live/mount/rootfs/filesystem.squashfs/bin/ping = cap_net_raw+ep

We could of course make /bin/ping setuid root back, just as it has
always been, but with our firewall it'll only allow pinging the LAN; for
now, I'm deciding that the limited usefulness is not worth the security
implications (even though we confine ping with AppArmor), and ping will
remain root only for now. We'll see how much sensible complains we get
during the 2.0 beta and RC phases.

Thanks to journalctl's --output=cat option, we can trivially look at the
logged message itself, without any metadata around.

Test suite: use the Journal instead of the deprecated /var/log/syslog to extract information about packets dropped by the firewall.

I want to use time-sync.target (see systemd.special(7)), so that we can
order stuff after it.

But with Type=simple, we can't tell when htpdate is done, so we can't
specify that time-sync.target has not been reached until then. So let's
use Type=oneshot. But then, 20-time.sh would block until htpdate is
done, which is not what we want; this is solved by using --no-block when
restarting the service there.

... and pave the way for adding more options than the user to execute
the command as.

The one in Tor Browser 5.0 seems to take longer to start.

For some reason, on Jessie, running ping as a regular users results in "ping:
icmp open socket: Operation not permitted", with exit code == 2. But as root, it
"works" and the firewall blocks the packets. This is rather an improvement than
a problem (stuff is blocked earlier, which is cheaper), so let's just deal with
it in the test suite only, by running ping as root: the main purpose here is to
test the firewall.

This change also affects the netcat command used to open TCP and UDP
connections, for code simplicity's sake. Here again, the goal is to test
the firewall.