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

mike is concerned that we would get too much exposure to adversaries,
if we enforce that none of our L2 guards can be in the same family.

this change set now essentially finishes the feature that commit a77727cd
was attempting to add, but strips the "_and_family" part of that plan.

We had omitted some checks for whether our vanguards (second layer
guards from proposal 333) overlapped or came from the same family.
Now make sure to pick each of them to be independent.

Fixes bug 40639; bugfix on 0.4.7.1-alpha.

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

Remove UPTIME_TO_GUARANTEE_STABLE, MTBF_TO_GUARANTEE_STABLE,
TIME_KNOWN_TO_GUARANTEE_FAMILIAR WFU_TO_GUARANTEE_GUARD and replace each
of them with a tunnable torrc option.

Related to #40652

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

Related to #40652

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

Fixes #40649

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

Fixes #40604

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

Previously, `channelpadding_get_netflow_inactive_timeout_ms` would
crash with an assertion failure if `low_timeout` was greater than
`high_timeout`. That wasn't possible in practice because of checks
in `channelpadding_update_padding_for_channel`, but it's better not
to have a function whose correctness is this tricky to prove.

Fixes #40645.  Bugfix on 0.3.1.1-alpha.

Fix from previous commit where a DESTROY cell is sent instead of a
TRUNCATED.

Related to #40623

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

Closes #40647

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

Note that with this commit, TRUNCATED cells won't be used anymore that
is client and relays won't emit them.

Fixes #40623

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

This also incidently removes a use of uninitialized stack data from the
connection_or_set_ext_or_identifier() function.

Fixes #40648

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

LibreSSL is now closer to OpenSSL 1.1 than OpenSSL 1.0. According to
https://undeadly.org/cgi?action=article;sid=20220116121253, this is the
intention of OpenBSD developers.

According to #40630, many special cases are needed to compile Tor against
LibreSSL 3.5 when using Tor's OpenSSL 1.0 compatibility mode, whereas only a
small number of #defines are required when using OpenSSL 1.1 compatibility
mode. One additional workaround is required for LibreSSL 3.4 compatibility.

Compiles and passes unit tests with LibreSSL 3.4.3 and 3.5.1.