Perform a clean shutdown in case worker threads cannot be lauched.

In the circuit_about_to_free(), we clear the circ->conflux object and then we
end up trying to emit an event on the control port which calls
CIRCUIT_IS_CONFLUX() and non fatal assert on the false branch.

Fixes #41037

Signed-off-by: David Goulet <dgoulet@torproject.org>

After we added layer-two vanguards, directory authorities wouldn't
think any of their vanguards were suitable for circuits, leading
to a "Failed to find node for hop #2 of our path. Discarding
this circuit." log message once per second from startup until
they made a fresh consensus. Now they look to their existing
consensus on startup, letting them build circuits properly from
the beginning.

Fixes bug 40802; bugfix on 0.4.7.1-alpha.

These would fail if anybody actually still used OpenSSL 1.0, but in any case
there's no need to leave them around.

Follow-up from !862 (comment 3178084).

This will cause clients before 0.4.1.1-alpha to shut down.

Part of #40836.

Note that the changes here will require all relays
to be 0.4.7.4-alpha or later, which is lower than
our current lowest-supported relay version.

Part of #40836.

Unfortunately, we wanted to be able to control the Guard flag here but the
token used mentionned "exit" instead.

Oh well, s*** happens :).

Fixes #41035

Signed-off-by: David Goulet <dgoulet@torproject.org>

Fixes bug #41034; bug not in any released tor.

Signed-off-by: David Goulet <dgoulet@torproject.org>

Related to #41023

Signed-off-by: David Goulet <dgoulet@torproject.org>

This was put in when HSv2 and v3 were co-existing. Now, the network requires
HSRend=2 which is v3 by default.

This is a simple cleanup of an internal flag used to identify a launch of a
RPv3 circuit.

Related to #41023

Signed-off-by: David Goulet <dgoulet@torproject.org>

Broken with my happy-family-sandbox patch;
bug not in any released Tor.

I have no idea why this just showed up for me.
I guess it has something to do with GCC, but I'm not sure.

Closes #41032.

This involves a more-than-usual bit of code churn in the generated C,
since the context argument is now gone.

This is all unreachable now, so we can tear it out
and simplify things a bit.

Previously they used RSA+TlsSecret auth, but that's about
to go away even more.

Closes #41022.

Bug not in any released version of Tor.

(The sandbox code will need this.)

Before we could rely on RFC5705 key material exporters,
we did a fairly hinky thing involving the client random,
the server random, and the master secret.  These fields
are all opaque in sensible TLS libraries,
and the master secret is quite sensitive.
Therefore, we're removing them.

Some code still refers to them, but it does so behind
a `define(HAVE_WORKING_TOR_TLS_GET_TLSSECRETS)` check,
which macro is now never defined.

Part of #41020.

(Actually, most of them can remain: we just convert them
to test Ed25519+RFC5709 authentication instead.)

(Requested by @nusenu)

I'm hoping that this design will be a bit more ergonomic
than my first idea; the improvement here is that you have to list the family
IDs you expect in your torrc.  This way, there's a cross-check between the
actual keys we use and your configuration for them.