This is related to the rest of 523587a5

Using the *_array() functions here confused coverity, and was actually
a bit longer than we needed.  Now we just use macros for the repeated
bits, so that we can mention a file and a suffix-appended version in
one line.

Conflicts:
	src/or/circuitlist.c

Specifically, count the age of the data queued in a linked directory
connection's buffers when counting a stream's age.

Another part of 11792.

Part of 11792.

(Uses the zlib-endorsed formula for memory needs for inflate/deflate
from "zconf.h".)

We had some code to fix up the 'status' return value to -1 on error
if it wasn't set, but it was unreachable because our code was
correct.  Tweak this by initializing status to -1, and then only
setting it to 0 on success.  Also add a goto which was missing: its
absence was harmless.

[CID 718614, 718616]

[CID 1205014]

This allows coverity to infer that we aren't leaking them.

[Fixes a lot of CIDs]

Found by coverity, which noticed that if you said
  tor-gencert -i identity1 -i identity2
we would leak "identity1".

[CID 1198201, 1198202, 1198203]

Also explain why we aren't checking its return value.

[CID 1198197]

Also, make it clearer that chunks cannot be NULL

[CID 1031750, 1031751]

The unsigned underflow here is defined and intentional.

CID 202482

This was freaking out coverity.

[CID 743379]

The unsigned underflow here is defined and intentional.

CID 202482

[CID 718609]

(We allowed it previously, but produced an LD_BUG message when it
happened, which is not consistent

Also, remove inconsistent NULL checks before calling
rend_service_intro_free.

(Removing the check is for CID 718613)

Coverity doesn't like doing NULL checks on things that can't be
NULL; I like checking things where the logic for their not being
NULL is nontrivial.  Let's compromise, and make it obvious that this
field can't be NULL.

[Coverity CID 202004]

(It's LD_BUG to reach this point because the hashed password values
were tested earlier from options_validate)

[Coverity CID 1232091]

Coverity thinks that when we do "double x = int1/int2;", we probably
meant "double x = ((double)int1) / int2;".  In these cases, we
didn't.

[Coverity CID 1232089 and 1232090]

[Coverity CID 1232087 and 1232088]

(Coverity thinks that "if (a) X; else X;" is probably a bug.)

[Coverity CID 1232086]

Fixes issue 10116

Previously, we had documented it to return -1 or 0, when in fact
lseek returns -1 or the new position in the file.

This is harmless, since we were only checking for negative values
when we used tor_fd_seekend.

Closes ticket 12061. Based on a patch from "carlo von lynX" on tor-dev at
  https://lists.torproject.org/pipermail/tor-dev/2014-April/006705.html