Client side, when a descriptor is finally fetched and stored in the cache, we
then go over all pending SOCKS request for that descriptor. If it turns out
that the intro points are unusable, we close the first SOCKS request but not
the others for the same .onion.

This commit makes it that we'll close all SOCKS requests so we don't let
hanging the other ones.

It also fixes another bug which is having a SOCKS connection in RENDDESC_WAIT
state but with a descriptor in the cache. At some point, tor will expire the
intro failure cache which will make that descriptor usable again. When
retrying all SOCKS connection (retry_all_socks_conn_waiting_for_desc()), we
won't end up in the code path where we have already the descriptor for a
pending request causing a BUG().

Bottom line is that we should never have pending requests (waiting for a
descriptor) with that descriptor in the cache (even if unusable).

Fixees #27410.

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

Tor2web was never implemented for v3 onion services.

(Even if it only affects a few relay operators.)

The required protocol version check occurs before the consensus flavour
check. So on directory mirrors (and some client configs), alpha users need
to delete both consensus flavours to workaround nss bugs.

Closes ticket 27756.

Duplicate comes from introducing this define into 0.2.9, which did not yet
have KIST.

This mocking was not available in 0.2.9.

This avoids asymmetry in our public relay stats, which can be exploited for
guard discovery and other attacks.

The rest of rephist uses uint64_t internally. Let's make these take it too,
so we don't have to worry about overflowing size_t on 32 bit systems.

This shouldn't be a user-visible change: nobody has a 16 MB RSA
key that they're trying to use with Tor.

I'm doing this to fix CID 1439330 / ticket 27730, where coverity
complains (on 64-bit) that we are making a comparison that is never
true.

This is really annoying, since we can't use cfg(test) for doctests.

Closes ticket 27288