Update ns downloads when we receive a bridge descriptor

This prevents long stalls when we're starting with a state file but
with no bridge descriptors.  Fixes bug 9229.  I believe this bug has
been present since 0.2.0.3-alpha.
Fix our check for the "first" bridge descriptor.

This is meant to be a better bug 9229 fix -- or at least, one more
in tune with the intent of the original code, which calls
router_retry_directory_downloads() only on the first bridge descriptor.
should_disable_dir_fetches() now returns 1 if DisableNetwork==1

This change prevents LD_BUG warnings and bootstrap failure messages
when we try to do directory fetches when starting with
DisableNetwork == 1, a consensus present, but no descriptors (or
insufficient descriptors) yet.

Fixes bug 11200 and bug 10405.  It's a bugfix on 0.2.3.9-alpha.
Thanks to mcs for walking me through the repro instructions!
Give no answer, not NOTIMPL, for unsupported DNS query types

According to reports, most programs degrade somewhat gracefully on
getting no answer for an MX or a CERT for www.example.com, but many
flip out completely on a NOTIMPL error.

Also, treat a QTYPE_ALL query as just asking for an A record.

The real fix here is to implement proposal 219 or something like it.

Fixes bug 10268; bugfix on 0.2.0.1-alpha.

Based on a patch from "epoch".
Make num_bridges_usable work properly.

My first implementation was broken, since it returned "whether there
is one bridge" rather than "how many bridges."

Also, the implementation for the n_options_out feature in
choose_random_entry_impl was completely broken due to a missing *.
Supply better and less frequent warnings on circID exhaustion

Fixes the surface behavior of #11553
Switch to random allocation on circuitIDs.

Fixes a possible root cause of 11553 by only making 64 attempts at
most to pick a circuitID.  Previously, we would test every possible
circuit ID until we found one or ran out.

This algorithm succeeds probabilistically. As the comment says:

  This potentially causes us to give up early if our circuit ID
  space is nearly full.  If we have N circuit IDs in use, then we
  will reject a new circuit with probability (N / max_range) ^
  MAX_CIRCID_ATTEMPTS.  This means that in practice, a few percent
  of our circuit ID capacity will go unused.

  The alternative here, though, is to do a linear search over the
  whole circuit ID space every time we extend a circuit, which is
  not so great either.

This makes new vs old clients distinguishable, so we should try to
batch it with other patches that do that, like 11438.
Merge remote-tracking branch 'public/bug11553_024' into bug11553_025

Conflicts:
	src/or/channel.h
Diagnostic warning to see if it's pending destroys causing 11553
Add a rate-limiter for the other circuitID exhaustion warning
Merge remote-tracking branch 'public/bug11553_024' into bug11553_025
scan-build: Add a check for result from getaddrinfo

As documented, getaddrinfo always sets its result when it returns
no error.  But scan-build doesn't know that, and thinks we might
be def
scan-build: check impossible null-pointer case in buffers.c

When maintaining buffer freelists, we don't skip more than there
are, so (*chp) can't be null to begin with.  scan-build has no way
to know that.
scan-build: circuit_cpath_support_ntor had a dead initialization

We were initializing cpath twice, which doesn't make sense.
scan-build: Avoid crashing on BUG in circuit_get_by_rend_token_and_purpose

If we fail in circuit_get_by_rend_token_and_purpose because the
circuit has no rend_info, don't try to reference fiends from its
rend_info when logging an error.  Bugfix on 8b9a2cb68, which is
going into Tor 0.2.5.4-alpha.
scan-build: fix a crash-on-fail possibility in test_policy.c
scan-build: Be consistent with a needless check in circuitmux.c

In circuitmux_detach_all_circuits, we check whether an HT iterator
gives us NULL.  That should be impossible for an HT iterator.  But
our checking it has confused scan-build (justly) into thinking that
our later use of HT_NEXT_RMV might not be kosher.  I'm taking the
coward's route here and strengthening the check.  Bugfix on
fd31dd44. (Not a real bug though)
scan-build: when logging a path length, check build_state.

Throughout circuituse, when we log about a circuit, we log its
desired path length from build_state. scan-build is irrationally
concerned that build_state might be NULL.
scan-build: get_proxy_addrport should always set its outputs

When get_proxy_addrport returned PROXY_NONE, it would leave
addr/port unset. This is inconsistent, and could (if we used the
function in a stupid way) lead to undefined behavior. Bugfix on
5b050a9b0, though I don't think it affects tor-as-it-is.
scan-build: in cpuworker, initialize tv_start

scan-build doesn't realize that a request can't be timed at the end
unless it's timed at the start, and so it's not possible for us to
be subtracting start from end without start being set.
Nevertheless, let's not confuse it.