Check if we can stop restarting tor in 10-tor.sh
Restarting tor via NM, without coordination with Tor Connection, causes all sorts of trouble.
Here's the code:
```
# We would like Tor to be started during init time, even before the
# network is up, and then send it a SIGHUP here to make it start
# bootstrapping swiftly, but it doesn't work because of a bug in
# Tor. Details:
# * https://gitlab.torproject.org/tpo/core/tor/-/issues/1247
# * https://gitlab.tails.boum.org/tails/tails/-/blob/7fae4a761a06e5a14048baff21e0bdb71a1f7226/wiki/src/bugs/tor_vs_networkmanager.mdwn
# To work around this we restart Tor.
systemctl restart tor@default.service
```
Above links, but clickable:
- https://gitlab.torproject.org/tpo/core/tor/-/issues/1247
- https://gitlab.tails.boum.org/tails/tails/-/blob/7fae4a761a06e5a14048baff21e0bdb71a1f7226/wiki/src/bugs/tor_vs_networkmanager.mdwn
Is this still necessary?
Would a SIGHUP (aka. `systemctl reload tor@default.service`) suffice?
# Test plan
- [ ] Check how this relates to http://eweiibe6tdjsdprb4px6rqrzzcsi22m4koia44kc5pcjr7nec2rlxyad.onion/tpo/core/tor/-/issues/40499
- [x] Check if in the most trivial scenario, a SIGHUP is sufficient:
1. start Tails
2. close _Tor Connection_
3. replace this `restart` with `reload`
4. connect to Tor via _Tor Connection_
5. disconnect from the network
6. wait 15 minutes
7. reconnect to the network
8. tor should resume working
- _Tor Connection_ waits for direct connection to bootstrap, which times out: actually, Tor as already bootstrapped and is working fine, so it does not need to bootstrap again, but apparently _Tor Connection_ does not know this. Essentially, the `restart` we currently have hides a more fundamental disconnect between the actual status of the tor client and the status of `tails-tor-has-bootstrapped.target`; once we don't force a new bootstrap anymore via restarting, the problem becomes visible: in some cases tor has bootstrapped but that systemd target is down, which makes some sense since tor is not usable (we're offline, remember), but is problematic because _Tor Connection_ does not know it should not wait for a bootstrap to happen.
- then _Tor Connection_ retries using default bridges, which successfully bootstraps
- [x] Trivial scenario, but waiting 2+ hours in order to gain confidence that waiting 15 min is sufficient for the remaining tests: same result as when waiting 15 minutes
- [ ] Trivial scenario, but with default bridges
- [ ] Trivial scenario, but with custom bridges
- [ ] Suspend to RAM and resume 15 minutes later
- [ ] Disconnect then reconnect from a different network 15 minutes later
- [ ] Brainstorm more elaborate test scenarios, aka. "what can possibly go wrong if we reload instead of restarting?"
issue