Everything that accepted the 'Circ' name handled it wrong, so even now
that we fixed the handling of the parameter, we wouldn't be able to
set it without making all the 0.2.2.7..0.2.2.10 relays act wonky.
This patch makes Tors accept the 'Circuit' name instead, so we can
turn on circuit priorities without confusing the versions that treated
the 'Circ' name as occasion to act weird.

When you mean (a=b(c,d)) >= 0, you had better not say (a=b(c,d)>=0).
We did the latter, and so whenever CircPriorityHalflife was in the
consensus, it was treated as having a value of 1 msec (that is,
boolean true).

Conflicts:

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

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.

Zax from #tor noticed that while we list docbook-xsl and docbook-xml
in our helpful error text when making the docs fails, we forgot to
also list libxml2-utils. Let's add that.

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.

it's perfect, let's ship it

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.