Previously, if they changed in torrc during a SIGHUP, all was well,
since we would just clear all transient entries from the addrmap
thanks to bug 1345.  But if you changed them from the controller, Tor
would leave old mappings in place.

The VirtualAddrNetwork bug has been here since 0.1.1.19-rc; the
AutomapHosts* bug has been here since 0.2.0.1-alpha.

This bug couldn't happen when TrackExitHosts changed in torrc, since
the SIGHUP to reload the torrc would clear out all the transient
addressmap entries before.  But if you used SETCONF to change
TrackExitHosts, old entries would be left alone: that's a bug, and so
this is a bugfix on Tor 0.1.0.1-rc.

If you really want to purge the client DNS cache, the TrackHostExits
mappings, and the virtual address mappings, you should be using NEWNYM
instead.

Fixes bug 1345; bugfix on Tor 0.1.0.1-rc.

Note that this needs more work: now that we aren't nuking the
transient addressmap entries on HUP, we need to make sure that
configuration changes to VirtualAddressMap and TrackHostExits actually
have a reasonable effect.

We'll use this to detect changes in CSV options.

It does what it says on the tin.  It turns out I'll want this in a couple
of places.

We'll eventually want to do more work here to make sure that the ports
are stable over multiple invocations.  Otherwise, turning your node on
and off will get you a new DirPort/ORPort needlessly.

Otherwise, it will just immediately close any port declared with "auto"
on the grounds that it wasn't configured.  Now, it will allow "auto" to
match any port.

This means FWIW if you configure a socks port with SocksPort 9999
and then transition to SocksPort auto, the original socksport will
not get closed and reopened.  I'm considering this a feature.

This is the major part of the implementation for trac issue 3076.

HTTPS error code 403 is now reported as:
"The https proxy refused to allow connection".
Used a switch statement for additional error codes to be explained
in the future.

If we do a replace-then-munmap, windows will never actually rewrite
the microdesc cache.

Found by wanoskarnet; bugfix on 0.2.2.6-alpha.

The new behavior is to try to rename the old file if there is one there
that we can't read.  In all likelihood, that will fail too, but at least
we tried, and at least it won't crash.

Conflicts throughout.  All resolved in favor of taking HEAD and
adding tor_mem* or fast_mem* ops as appropriate.

	src/common/Makefile.am
	src/or/circuitbuild.c
	src/or/directory.c
	src/or/dirserv.c
	src/or/dirvote.c
	src/or/networkstatus.c
	src/or/rendclient.c
	src/or/rendservice.c
	src/or/router.c
	src/or/routerlist.c
	src/or/routerparse.c
	src/or/test.c

Here I looked at the results of the automated conversion and cleaned
them up as follows:

   If there was a tor_memcmp or tor_memeq that was in fact "safe"[*] I
   changed it to a fast_memcmp or fast_memeq.

   Otherwise if there was a tor_memcmp that could turn into a
   tor_memneq or tor_memeq, I converted it.

This wants close attention.

[*] I'm erring on the side of caution here, and leaving some things
as tor_memcmp that could in my opinion use the data-dependent
fast_memcmp variant.

This commit is _exactly_ the result of

perl -i -pe 's/\bmemcmp\(/tor_memcmp\(/g' src/*/*.[ch]
perl -i -pe 's/\!\s*tor_memcmp\(/tor_memeq\(/g' src/*/*.[ch]
perl -i -pe 's/0\s*==\s*tor_memcmp\(/tor_memeq\(/g' src/*/*.[ch]
perl -i -pe 's/0\s*!=\s*tor_memcmp\(/tor_memneq\(/g' src/*/*.[ch]
git checkout src/common/di_ops.[ch]
git checkout src/or/test.c
git checkout src/common/test.h

The tor_memcmp code is by Robert Ransom, and the tor_memeq code is
by me.  Both incorporate some ideas from DJB's stuff.