Fix typo

See merge request tpo/core/arti!441

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.

This replaces a hand-coded replacement that was probably a little
less efficient.

The code here uses a new iterator type, since I couldn't find one of
these on crates.io.  I tried writing the code without it, but it was
harder to follow and test.

We do this by creating a new FallbackSet type that includes status
information, and updating the GuardMgr APIs to record success and
failure about it when appropriate.  We can use this to mark
FallbackDirs retriable (or not).

With this change, FallbackDir is now stored internally as a Guard in
the GuardMgr crate.  That's fine: the FallbackDir type really only
matters for configuration.

This is the final step in allowing the CircMgr to use the GuardMgr's
view of the fallbacks.

Compilation is restored and tests pass.

If we're building a path with the guard manager involved, we now ask
the guard manager to pick our first hop no matter what.  We only
pick from the fallback list ourselves if we're using the API with no
guard manager.

This causes some follow-on changes where we have to remember an
OwnedChanTarget object in a TorPath we've built, and where we gain
the ability to say we're building a path "from nothing extra at
all."  Those are all internal to the crate, though.

Closes #220, by making sure that we use our guards to get a fresh
netdir (if we can) before falling back to any fallbacks, even if our
consensus is old.

Compilation should be fixed in the next commit.

We only do this when we fail to get a regular guard (e.g., because
they're all down), and when we have been asked for a guard for a
one-hop directory.

Most of the change in this commit is plumbing to make all of the
types match up.

As before, compilation may still be broken.

We need to extend our notion of "the origin of a guard" to include
"somewhere outside the guard list"; we need the ability to return a
FallbackDir as a Guard; and we need to remember a few more pieces of
information in each pending request.

As before, this commit may break compilation; it will be restored soon.

The guard manager is responsible for handing out the first hops of
tor circuits, keeping track of their successes and failures, and
remembering their states.  Given that, it makes sense to store this
information here.  It is not yet used; I'll be fixing that in
upcoming commits.

Arguably, this information no longer belongs in the directory
manager: I've added a todo about moving it.

This commit will break compilation on its own in a couple of places;
subsequent commits will fix it up.

This is more in keeping with the rest of our code.

This is the logical place for it, I think: the GuardMgr's job is to
pick the first hop for a circuit depending on remembered status for
possible first hops.  Making this change will let us streamline the
code that interacts with these objects.

Remove allow(clippy::disallowed_methods) lint flag.

See merge request tpo/core/arti!437

Make daemon tasks self-contained; introduce NetDirProvider

See merge request tpo/core/arti!436

The various background daemon tasks that `arti-client` used to spawn are
now handled inside their respective crates instead, with functions
provided to spawn them that return `TaskHandle`s.

This required introducing a new trait, `NetDirProvider`, which steals
some functionality from the `DirProvider` trait to enable `tor-circmgr`
to depend on it (`tor-circmgr` is a dependency of `tor-dirmgr`, so it
can't depend on `DirProvider` directly).

While we're at it, we also make some of the tasks wait for events from
the `NetDirProvider` instead of sleeping, slightly increasing
efficiency.