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.)

Unlike the rest of the crates, these don't have a "tor-" or "arti-"
prefix, and are potentially used by code outside arti.  With that in
mind, it's probably for the best not to bump them to 0.2.0 along
with the rest of our crates.

They have had no changes since 0.1.0 other than refactoring and
changing of clippy lints.  Therefore, I'm not bumping the
dependencies from other crates onto these: it's fine whether our
other crates use caret/retry-error 0.1.0 or 0.1.1.

Run cargo upgrade/update in preparation for 0.2.0

See merge request tpo/core/arti!444

Implement a directory munger to simulate pathological cases in arti-testing (v2)

Closes #397

See merge request tpo/core/arti!442

This feature allows us to detect different failing cases for
#329 that would otherwise be hard to induce.  It works by
filtering consensus directory objects and/or microdescriptor objects
before introducing them to the directory manager.

Closes #397.

This commit uses the `visibility` and `visible` crates to
conditionally make certain structs and their fields public
(respectively).  This is incredibly dangerous to use for anything
besides testing, and I've tried to write the documentation for the
feature accordingly.

Minor retry tuning to improve behavior under failing conditions.

See merge request tpo/core/arti!439

Replace the next delay field immediately rather than taking it and
_then_ setting it.  This way, it's never in an incorrect state.

Fix typo

See merge request tpo/core/arti!441

The older default seems (experimentally) to be ridiculously high.
Generally, if we can't build a circuit within a handful attempts,
that circuit has already timed out... unless there is a fast-failure
condition, in which case we're just hammering the network (or our
view of it.)

Found with `arti-testing` for #329.

Previously, if we had launch_parallelism > 1, and we were willing to
retry building a circuit max_retries times, then we'd launch up to
max_retries * launch_parallelism circuits before giving up.  Ouch!

With this patch, we try to keep the total number of circuits
planned and attempted to the actual max_retries limit.

Part of #329; found with arti-testing.

The previous algorithm had two flaws:

  * It would wait even after the final attempt, when there were no
    more retries to do.
  * It would fail to wait between attempts if an error occurred.

This refactoring fixes both of these issues, and adds some comments.

Refactor FallbackDir handling and implement a retry-after-delay mechanism.

Closes #406 and #220

See merge request tpo/core/arti!433

Manual merge for just this branch as per
  tpo/core/arti!433 (comment 2791982)
  tpo/core/arti!433 (comment 2791993)

The FirstHopId type now records an enum that stores whether the hop
is a guard or a fallback.  This change addresses concerns about
remembering to check the type or source of an Id before passing it
down to the FallbackState or GuardSet.

Making this change required an API change, so that dirmgr can
report success/failure status without actually knowing whether it's
using a fallback or a guard.

This is preparation for having separate GuardId and FirstHopId types
that distinguish which back-end they index.