This replaces the old FallbackConsensus notion, and should provide a
way -- assuming we pick reasonable nodes! -- to give clients
suggestions of placs to go to get their first consensus.

Now creating a dir_server_t and adding it are separate functions, and
there are frontend functions for adding a trusted dirserver and a
fallback dirserver.

We use trusted_dir_server_t for two pieces of functionality: a list of
all directory authorities, and a list of initial places to look for
a directory.  With this patch we start to separate those two roles.

There is as of now no actual way to be a fallback directory without being
an authority.

Fixes bug #7592; bugfix on 882b3896.

The bug is not present in any released versions of Tor.

"error=Unable to launch resolve request" is not a nice thing to tell
the controller.  Bugfix on 0.2.0.19-alpha (c11c48fc).

RFC1123 suggests that we should handle two-year times, and a full
range of time zones, and other stuff too.  We don't.

Fix for #6113.

Note that the RFC1123 times we generate still all say 'GMT'.  I'm
going to suggest this is not worth changing.

Affects comments only. For ticket 6849.

This one is necessary for sending BEGIN cells with sane flags when
self-testing a directory port.  All real entry connections were
getting their ipv{4,6}_traffic_ok flags set from their listeners, and
for begindir entry connections we didn't care, but for directory
self-testing, we had a problem.

Fixes at least one more case of 7493; if there are more lingering
cases of 7493, this might fix them too.

Bug not in any released version of Tor.

Looks like when i was writing the code to set the ipv4_traffic flag on
port_cfg_t, I missed some cases, such as the one where the port was
set from its default value.

Fix for 7493. Bug not in any released Tor.

Previously, I was freaking out about passing an unspec address to
dns_found_answer() on an error, since I was using the address type to
determine whether the error was an error on an ipv4 address lookup or
on an ipv6 address lookup.  But now dns_found_answer() has a separate
orig_query_type argument to tell what kind of query it is, so there's
no need to freak out.

This is imperfect, since it sends back whatever we would send to
a socks RESOLVE request, when in reality we should send back whatever
was asked for.

* If there's an IPv4 and an IPv6 address, return both in the resolved
  cell.
* Treat all resolve requests as permitting IPv6, since by the spec they're
  allowed to, and by the code that won't break anything.

IPv4-only exits have an implicit "reject [::]/0", which was making
policy_is_reject_star() return 1 for them, making us refuse to do
hostname lookups.

This fix chanes policy_is_reject_star() to ask about which family we meant.

We had some old code to send back connected cells for IPv6 addresses,
but it was wrong.  Fortunately, it was also unreachable.

The code previously detected wildcarding and replaced wildcarded
answers with DNS_STATUS_FAILED_PERMANENT.  But that status variable
was no longer used!  Remove the status variable, and instead change
the value of 'result' in evdns_callback.

Thank goodness for compiler warnings. In this case,
unused-but-set-variable.

Thanks to Linus for finding this one.