of a channel.

At first I wanted to have this information not be a part of channels
at all, but it is a fairly tiny amount of data, and the alternatives
are pretty crufty.

Downgrade `rlimit` to 0.7.

See merge request tpo/core/arti!449

Upstream 0.8.2 has broken compilation with Rust 1.53; versions
0.8.{0,1} have been yanked.

Possibly by the time the next arti version comes out, they'll have
fixed this situation, or we'll have upgraded our MSRV.

Upstream issue at https://github.com/Nugine/rlimit/issues/42 .

# Conflicts:
#   doc/semver_status.md

Treat expired/not-yet-valid directory objects as Errors.

Closes #431

See merge request tpo/core/arti!448

Doing this will make us treat caches that send us these objects as
not-working, and close circuits to them instead of trying over and
over.

The case where we add a document from the cache requires special
handling: it isn't actually a error to find an expired document in
our cache (unless the passage of time itself is erroneous, which is
a debatable proposition at best).

Fixes #431.

Improved handling for retriable errors in circmgr

Closes #427 and #421

See merge request tpo/core/arti!443

# Conflicts:
#   doc/semver_status.md

The old version of this function was error-prone, and in fact had
errors: it was too easy to forget to add non-persistent fields, and
that's exactly what we forgot in a few cases
(`microdescriptor_missing`, `circ_history`, and
`suspicious_behavior_warned`).

The new version of this function consumes both of the incoming
Guards, and constructs every field explicitly so that we can't
forget to list any.

Closes #429.

Previously, we treated successfully building a circuit to a guard as
a "success", and any failure, including a directory cache failure,
as a failure.  With this change, guards now have separate
success/failure and retry status for circuit usage and directory
usage.

This change is needed for guard-as-directory retry to have
reasonable behavior.  Otherwise, when a guard succeeds at building a
circuit, that clears the directory-is-failing status and makes us
retry the guards to quickly.

This will help when we give Guards a DirStatus as well.

Previously the code would do stuff like

```
    schedule = RetrySchedule::new(INITIAL_DELAY);
```

which is needlessly verbose, since the schedule already keeps track
of its initial delay.

It's about to be shared between fallbacks and guards.

This lets us say that the UsageMismatch cases in some parts of the
code reflect a programming error (RetryTime::Never), whereas in
other case it reflects another circuit request getting to the
circuit first (RetryTime::Immediate).

For each case, describe its semantics (in addition to when you would
create it).

Explain the relationship between After and At.

Stop saying "Strategy": we renamed this type to "RetryTime".

Also add tests for RetryTime comparison functions to make sure they
work as expected.

Use the new RetryTime type and its associates to decide how long to
wait (if at all) between attempts to build a circuit.

Closes #421.

Part of #329.

Previously we did not distinguish errors that came from pending
circuits from errors that came from the circuits we were
building.  We also reported errors as coming from "Left" or "Right",
instead of a more reasonable description.

We were treating restrict_mut() failures as internal errors, and
using internal errors to represent them.  But in fact, these
failures are entirely possible based on timing.  Here's how it
happens:

* Two different circuit requests arrive at the same time, and both
  notice a pending circuit that they could use.
* The pending circuit completes; both pending requests are notified.
* The first request calls restrict_mut(), and restricts the request
  in such a way that the second couldn't use it.
* The second request calls restrict_mut(), and gets a failure.

Because of this issue, we treat these errors as transient failures
and just wait for another circuit.

Closes #427.

(This is not a breaking API change, since `AbstractSpec` is a
crate-private trait.)

Miscellaneous test coverage work

See merge request tpo/core/arti!446

This is necessary to fix build for M1 apples.

Bump versions in preparation for 0.2.0 release.

See merge request tpo/core/arti!445

Not all of these strictly need to be bumped to 0.2.0; many could go
to 0.1.1 instead.  But since everything at the tor-rtcompat and
higher layers has had breaking API changes, it seems not so useful
to distinguish.  (It seems unlikely that anybody at this stage is
depending on e.g. tor-protover but not arti-client.)