On any failing case in test_util_config_line, we would leak a couple
of strings.

This was left over from an early draft of the microdescriptor code; it
began to populate the signatures array of a networkstatus vote, even
though there's no actual need to do that for a vote.

In its zeal to keep me from saying memset(x, '0', sizeof(x)), Coverity
disallows memset(x, 48, sizeof(x)).  Fine.  I'll choose a different
magic number, see if I care!

In C, the code "char x[10]; if (x) {...}" always takes the true branch of
the if statement.  Coverity notices this now.

In some cases, we were testing arrays to make sure that an operation
we wanted to do would suceed.  Those cases are now always-true.

In some cases, we were testing arrays to see if something was _set_.
Those caes are now tests for strlen(s), or tests for
!tor_mem_is_zero(d,len).

Every or conn has an outbuf, but coverity has no way of knowing that.
Add an assert to ease its conscience.

The first happens on an error case when a controller wants an
impossible directory object.  The second happens when we can't write
our fingerprint file.

The code for these was super-wrong, but will only break things when we
reset an option on a platform where sizeof(time_t) is different from
sizeof(int).

Conflicts:
	ChangeLog

Spotted by xmux; bugfix on 0.2.0.10-alpha.
(Bug introduced by 20b10859)

See task 1114. The most plausible explanation for someone sending us weak
DH keys is that they experiment with their Tor code or implement a new Tor
client. Usually, we don't care about such events, especially not on warn
level. If we really care about someone not following the Tor protocol, we
can set ProtocolWarnings to 1.

One was a simple buffer overrun; the other was a high-speed pointer
collision.  Both were introduced by my microdescs branch.

The old flavored consensus URL format made it harder to decode URLs
based on their prefixes, and didn't take into account our "only give
it to me if it's signed by enough authorities" stuff.

The point of doing SHA256 twice is, generally, is to prevent message
extension attacks where an attacker who knows H(A) can calculate
H(A|B).  But for attaching a signature to a document, the attacker
already _knows_ A, so trying to keep them from calculating H(A|B) is
pointless.

This means we need to handle the existence of multiple flavors of signature
in a detached signatures document, generate them correctly, and so on.

This patch introduces a new type called document_signature_t to represent the
signature of a consensus document.  Now, each consensus document can have up
to one document signature per voter per digest algorithm.  Also, each
detached-signatures document can have up to one signature per <voter,
algorithm, flavor>.

The consensus documents are not signed properly, not served, and not
exchanged yet.

The original proposal was vague and would have made older Tors reject
detached-signature documents as soon as they saw one with flavors.

Previously, we insisted that a valid signature must be a signature of
the expected digest.  Now we accept anything that starts with the
expected digest.  This lets us include another digest later.