We need to make sure we have an event_base in dns.c before we call
anything that wants one. Make sure we always have one in dns_reset()
when we're a client. Fixes bug 1341.

If no authority votes on any params, Tor authorities segfault when
trying to make a new consensus from the votes. Let's change that.

Found by Oğuz

Now if you're a published relay and you set RefuseUnknownExits, even
if your dirport is off, you'll fetch dir info from the authorities,
fetch it early, and cache it.

In the future, RefuseUnknownExits (or something like it) will be on
by default.

reported by atagar; fixes bug 1289.

If asciidoc is required, the user receives an error message telling
them about the --disable-asciidoc configure switch and the build
breaks.

now's your chance to destabilize it

Conflicts:

	ChangeLog
	configure.in
	contrib/tor-mingw.nsi.in
	src/win32/orconfig.h

Apparently this is not as obvious as I thought.

Conflicts:
	src/or/config.c
	src/or/test.c

From http://archives.seul.org/tor/relays/Mar-2010/msg00006.html :

   As I understand it, the bug should show up on relays that don't set
   Address to an IP address (so they need to resolve their Address
   line or their hostname to guess their IP address), and their
   hostname or Address line fails to resolve -- at that point they'll
   pick a random 4 bytes out of memory and call that their address. At
   the same time, relays that *do* successfully resolve their address
   will ignore the result, and only come up with a useful address if
   their interface address happens to be a public IP address.

Also, differentiate the two log messages.

I still feel like we should investigate this case. It seems odd.

Also break the build if that switch isn't used and asciidoc isn't
available.

We don't need sed for our string manipulation, so let's get rid of
it. Suggested by weasel.

Otherwise, the build process breaks when one of the .1.txt gets
a new mtime. Suggested by weasel.

Conflicts:
	src/common/test.h
	src/or/test.c

When the bandwidth-weights branch added the "directory-footer"
token, and began parsing the directory footer at the first
occurrence of "directory-footer", it made it possible to fool the
parsing algorithm into accepting unsigned data at the end of a
consensus or vote.  This patch fixes that bug by treating the footer
as starting with the first "directory-footer" or the first
"directory-signature", whichever comes first.