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.

I have a theory that my tests will work better if the code I'm testing
isn't disabled.

Now, every cached_resolve_t can remember an IPv4 result *and* an IPv6
result.  As a light protection against timing-based distinguishers for
IPv6 users (and against complexity!), every forward request generates
an IPv4 *and* an IPv6 request, assuming that we're an IPv6 exit.  Once
we have answers or errors for both, we act accordingly.

This patch additionally makes some useful refactorings in the dns.c
code, though there is quite a bit more of useful refactoring that could
be done.

Additionally, have a new interface for the argument passed to the
evdns_callback function.  Previously, it was just the original address
we were resolving.  But it turns out that, on error, evdns doesn't
tell you the type of the query, so on a failure we didn't know whether
IPv4 or IPv6 queries were failing.

The new convention is to have the first byte of that argument include
the query type.  I've refactored the code a bit to make that simpler.

Also, fix the function so it actually looks at our ipv6 exit policy.

This uses advertised IPv6 ports as an implicit version check.