We define "coming back online" as happening when a guard attempt
succeeds, if that attempt that was launched when we seemed to be
offline.

We define "seeming to be offline" as having all of our primary
guards marked unreachable, and having received no incoming network
traffic in a while.

Closes #216.

We need this for the circuit timeout estimator (#57).  It needs to
know "how recently have we got some incoming traffic", so that it
can tell whether a circuit has truly timed out, or whether the
entire network is down.

I'm implementing this with coarsetime, since we need to update these
in response to every single incoming cell, and we need the timestamp
operation to be _fast_.

(This reinstates an earlier commit, f30b2280, which I reverted
because we didn't need it at the time.)

Closes #179.

Basically the same thing as 371437d3
("Refactor tor_proto::channel::Reactor to use an UnboundedSender"), but
for tor_proto::circuit's Reactor instead.

(part of arti#217)

There wasn't any good reason for tor-proto's channel reactor to use a
shedload of oneshot channels instead of just an mpsc UnboundedSender,
and the whole `CtrlResult` thing made even less sense.

Straighten this code out by replacing all of that machinery with a
simple UnboundedSender, instead.

(part of arti#218)

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

This doesn't actually do the right thing: it will make somebody get
ignored completely for a release if they _only_ use their
alternative name.

Disclaimer: I have no idea what I'm doing when it comes to shell
scripts.

maint/thanks.sh autogenerates a list of contributors since a revision
(that you pass it on the command line), intended to make the work of
going through the shortlog a bit less manual. It can exclude
contributors' names given in maint/exclude_contributors.txt, in order to
filter out people who work for Tor, or who commit under more than one
name.

Most of the structs in `arti-client` have example code now, to give a
clearer idea of how they're used.

Annoyingly, a lot of the types exposed in `arti-client` are actually
re-exports, which makes documentation a bit harder: example code that
references other parts of `arti-client` can't actually be run as a
doctest, since the crate it's in is a dependency of `arti-client`.

We might be able to fix this in future by doing the documentation in
`arti-client` itself, but rustdoc seems to have some weird behaviours
there that need to be investigated first (for example, it seems to merge
the re-export and original documentation, and also put the re-export
documentation on the `impl` block for some reason).

For now, though, this commit just writes the docs from the point of view
of an `arti-client` consumer, removing notes specific to the crate in
which they're defined. It's not ideal, but at least the end user
experience is decent.

Instead of putting a fully qualified name in the text, in most cases
we should just use the short name of the type or function we're
referring to.

In other words, instead of saying [`crate::module::Foo`], we should
typically say [`Foo`](crate::module::Foo).

I'm not 100% sure this is better, but it might help the user
understand how Arti works a bit better.