This patch moves curve25519_keypair_t from src/or/onion_ntor.h to
src/common/crypto_curve25519.h, and adds new functions to generate,
load, and store keypairs.

Previously, we only used the strong OS entropy source as part of
seeding OpenSSL's RNG.  But with curve25519, we'll have occasion to
want to generate some keys using extremely-good entopy, as well as the
means to do so.  So let's!

This patch refactors the OS-entropy wrapper into its own
crypto_strongest_rand() function, and makes our new
curve25519_secret_key_generate function try it as appropriate.

The ntor handshake--described in proposal 216 and in a paper by
Goldberg, Stebila, and Ustaoglu--gets us much better performance than
our current approach.

We want to use donna-c64 when we have a GCC with support for
64x64->uint128_t multiplying.  If not, we want to use libnacl if we
can, unless it's giving us the unsafe "ref" implementation.  And if
that isn't going to work, we'd like to use the
portable-and-safe-but-slow 32-bit "donna" implementation.

We might need more library searching for the correct libnacl,
especially once the next libnacl release is out -- it's likely to have
bunches of better curve25519 implementations.

I also define a set of curve25519 wrapper functions, though it really
shouldn't be necessary.

We should eventually make the -donna*.c files get build with
-fomit-frame-pointer, since that can make a difference.

There was one place in curve25519-donna-c64 that was relying on
unaligned access and relying on little-endian values.  This patch
fixes that.

I've sent Adam a pull request.

This is copied from Adam Langley's curve25519-donna package, as
of commit 09427c9cab32075c06c3487aa01628030e1c5ae7.

I'm going to use this for looking op keys server-side for ntor.

This is a customizable extract-and-expand HMAC-KDF for deriving keys.
It derives from RFC5869, which derives its rationale from Krawczyk,
H., "Cryptographic Extraction and Key Derivation: The HKDF Scheme",
Proceedings of CRYPTO 2010, 2010, <http://eprint.iacr.org/2010/264>.

I'm also renaming the existing KDF, now that Tor has two of them.

This is the key derivation scheme specified in ntor.

There are also unit tests.

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.