This came up on #21035, where somebody tried to build on a linux
system with kernel headers including CLOCK_MONOTONIC_COARSE, then
run on a kernel that didn't support it.

I've adopted a belt-and-suspenders approach here: we detect failures
at initialization time, and we also detect (loudly) failures later on.

Fixes bug 21035; bugfix on 0.2.9.1-alpha when we started using
monotonic time.

This helps protect against bugs where any part of a buf_t's memory
is passed to a function that expects a NUL-terminated input.

It also closes TROVE-2016-10-001 (aka bug 20384).

("ours" merge because there is a separate 20384 patch for 026)

This helps protect against bugs where any part of a buf_t's memory
is passed to a function that expects a NUL-terminated input.

(ours merge -- there is a separate 0.2.5 patch for 20384.)

This helps protect against bugs where any part of a buf_t's memory
is passed to a function that expects a NUL-terminated input.

"Ours" merge to avoid version bump.

"ours" merge to avoid version bump.

Replace the 81 remaining fallbacks of the 100 originally introduced
in Tor 0.2.8.3-alpha in March 2016, with a list of 177 fallbacks
(123 new, 54 existing, 27 removed) generated in December 2016.

Resolves ticket 20170.

In get_token(), we could read one byte past the end of the
region. This is only a big problem in the case where the region
itself is (a) potentially hostile, and (b) not explicitly
nul-terminated.

This patch fixes the underlying bug, and also makes sure that the
one remaining case of not-NUL-terminated potentially hostile data
gets NUL-terminated.

Fix for bug 21018, TROVE-2016-12-002, and CVE-2016-1254

Fixes 20935.

Closes #20938

Signed-off-by: David Goulet <dgoulet@torproject.org>

Makes 19926 less annoying in 0.2.9.  In 0.3.0, we should actually
fix this.