Unused yet.

Most connections from the Tor network to non-onion OFTC servers are blocked
these days.

According to dir-spec.txt a new consensus is published at fresh-until,
which is valid-after + 1 hour. Since we always fetch a new consensus
on boot we can narrow the time points we set the time to to the middle
of [valid-after, fresh-until], and since fresh-until = valid-after + 1
hour, that means we set the time to valid-after + 30 minutes.

The benefit of this is that if htpdate fails then the user still gets
a time that is at most 30 minutes incorrect. This, incidentally, will
prevent the known problem with hidden services refusing connections.

First, it's much simpler and robust than running it from the time sync'
NetworkManager hook.

Second, it fixes seemingly random race conditions, when the notification would
be hidden by the GNOME desktop if shown before it.

If in the end we still got no Tor consensus, loudly abort the time
synchronization process.

* Avoid the "done" file to be created by a catched exception.
* Code simplification.
* A bit less verbose debugging messages.

This avoids more delays, and reduces Tails fingerprinting possibilities.

We previously removed unverified-consensus and restarted Tor in order to get
a proper cached-consensus. A HUP will make Tor continue happily using
unverified-consensus. We were earlier unsure whether that was safe or not, but
now we know it is.

Given Tor gives no strong meaning to the unverified-consensus vs.
cached-consensus consensus files name, it makes no sense acting in function
of it.

This fixes a critical bug in the GUI.

The ChangeLog reads:

Bugfixes
--------

 * Fix link to bug reporting documentation which have moved

Some of the previous hostnames were more correct from a HTTP PoV as they avoided
a few HTTP redirects. However, Squeeze's wget is too limited or stubborn to
understand their certificates are valid, so let's use hostnames that make
it happy.

No commit message