In other words, always enable what we used to call "bridge mode",
i.e. that tor won't touch the network until the user has configured it
via Tor Launcher.

This also includes changing Tails Greeter's Network Configuration
setting to only be about whether to enable or disable networking.

... and disable it by default.

To make it easier to persist all of these settings.

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/

This might help, in case there's some aufs bug/optimization that prevents the
parent directory to be seen as updated by whatever udev uses to watch it.
In particular, I'm wary of the effects of the noxino option we're using.

refs: #9012

As explained on https://labs.riseup.net/code/issues/8328#note-5, it's
been broken for 16 months, it is still broken after the partial fix that
went in Tails 1.6, and the logic on which the detector is based cannot
work anymore. Reintroducing and porting this feature is now tracked
on #10560.

Closes: #8328
Refs: #10560

The backslashes construct a single line, so the comment will break
everything.

We've previously moved the udevadm mangling out of
tails-unblock-network.service, but the NM startup handling was left in there.
So, NM could possibly start before the MAC address has been spoofed, which we
need to avoid.

Another option would have been to add all of this to PostLogin, but it has so
little to do with the Greeter's job that I felt it would be nicer to have
PostLogin simply run a script that does all the work, so that most of it is
self-contained in our main Git repo. For the same reason, this commit also
imports the restricted network detector startup in the very same script.

Apparently, udevadm calls are not always honored when they're started from
tails-unblock-network.service, possibly because we started it in a non-blocking
way.

The default setting for `udevadm trigger' is --type=devices.
That's why systemd-udev-trigger.service runs it twice, once
with --type=subsystems, and then with --type=devices.

Given the racy behaviour I'm seeing in tails-unblock-network.service,
it seems worth doing exactly the same thing as systemd-udev-trigger does.

There's apparently a race condition somewhere. We've already seen cases when
a file we've just deleted was still visible to some other process for a short
amount of time, so let's try to be on the safe side.

This will provide better facilities for debugging, e.g. which exact step
currently fails the first time it's run.

In the current state of things, this change merely speeds up login a bit since
this allows us to start this service in a non-blocking way in Tails Greeter,
without losing the ability to retrieve its status and output later.

That's the first step towards Will-fix: #8327.

Also, we move the "start NetworkManager as soon as the network is unblocked"
logic to tails-unblock-network.service.

Previously, /usr/local/sbin/tails-unblock-network (started by
tails-unblock-network.service) would manually start NetworkManager services.
This feels ugly, since it encodes systemd unit ordering in /usr/local/sbin/,
while it really belongs to the unit files themselves.

So, we use:

 * Requires= to trigger the startup of the NM services;
 * Before= to ensure that said startup only happens once the network
   has been unblocked.

Note that tails-unblock-network.service is *not* WantedBy multi-user.target.
Otherwise, it would try to start on boot before the user has had the chance to
opt-out from MAC spoofing. And then it would fail, since its EnvironmentFile
(/var/lib/gdm3/tails.physical_security) does not exist yet.