As per
  tpo/core/arti#472
Experimentation convinced me the Mistrust should be within the
ConfigurationSources.

This is a benchmarking tool, and fs-mistrust doesn't like the
permissions in our CI.  The env var ARTI_FS_DISABLE_PERMISSION_CHECKS
is (of course) specific to arti.  Maybe it should be honoured here,
or this should be done via the config files.

But disabling this is fine for now.

Delete tor_dirmgr::Error::BadNetworkConfig

See merge request tpo/core/arti!506

Make the example config file into a template and move it to arti

See merge request tpo/core/arti!503

impl_standard_builder followup

See merge request tpo/core/arti!505

This was anomalous, in that it contains &'static str, rather than a
proper nested error (eg a config::ConfigError, maybe).

But in fact it tursn out it is now not constructed.  The last
construction site was removed a long time ago in
  Use derive_builder for Authority and FallbackDir.

I have Plans for this macro.  In particular:

 * I have a wip branch which tests that the Builder can be
   deserialised from an empty config (ie, that config reading
   of a config with a blank section for this item works).

 * I think we should autogenerate $Config::builder(),
   and promote that, rather than $ConfigBuilder::default().
   This macro could do that.

This macro is kind of derive-y.  Also it has a test in it, and failing
to call it could allow bugs to exist, as well as missing bits of API.
Putting it next to the structs makes it easy to see that it's actually
been called.

Teach DirMgr to use slightly untimely directories

Closes #467 and #412

See merge request tpo/core/arti!500

We expect that a user may copy this file and uses it as a starting
point for their own configuration.

When they do that, we don't want them to freeze the default config in
time.  Instead, we can expect them to uncomment settings they wish to
change.  Then when they upgrade arti, *other* settings will get the
new defaults, which I think is right.

Now,
  git-grep '^#[^ ]' crates/arti/src/arti-example-config.toml
has no ouptut.

This prepares us for the next commit.

The defaults are built into the code.  This is a doc-commented example
file, not the primary specification of what the defaults are.

This is redundant, because the defaults have to be supplied by the
config builders (usually via builder default attributes).

That this is actually done and correct is tested by the
`default_config()` test case in arti/src/cfg.rs.

Add this test even though our construction of the Default and Builder
ought to trivially ensure that it's true.

arti-config: Move cmdline to tor-config

See merge request tpo/core/arti!498

Improvements prompted by clippy, and disable one lint

See merge request tpo/core/arti!497

Provide and use macro for impl Derive via Builder

See merge request tpo/core/arti!499

Add correct serde(default) attrs for humantime_serde::option

See merge request tpo/core/arti!502

Discovered by a test case in my local tree.  The test case was
macro-generated by an extension of impl_standard_builder (which
macro istself currently awaiting review, arti!499)

Have also sent an MR to update the upstream docs
  https://github.com/jean-airoldie/humantime-serde/pull/8

The type of ret.map_err(codec_err_to_chan)? is ().  ISTM that
writing `let () = ` makes it clear that there is nothing there,
but the lint forbids this.

This lint is warn by default and trips here for me on current nightly.

It seems wrong to me.  We should be able to make it clear to the
reader that there is nothing here - note how this differs from the
lines below where Ready contains msg.  A let () binding is a good way
to do that.

I think the lint allow ought to be added everywhere, but that doesn't
seem easy right now - see this issue about maint/add_warning:
   tpo/core/arti#469

This does involve unwrap, but of course that can't fail unless the
formats fail, which would already panic (that's implied by format!).

This does not know anything about arti, only about TOML and Config.

Code motion, plus necessary import adjustments.

If we're happy with a directory from 3 days ago, we should say
"if-modified-since 3 days ago".

This patch is larger than I'd like, since I had to add &DirMgrConfig
as an argument to the functions that make a  consensus request.

Closes #467.

In our status reporting code, we consider an
expired-but-still-usable directory still bootstrapped, but not 100%
bootstrapped.

Since we want to be willing to use older consensuses, we don't
necessarily want to reset a download just because the consensus is
expired.

This new behavior isn't ideal either; I've added a TODO that relates
to #433.

Related of #412

This new section describes how much variance we accept when it comes
to expired and not-yet-valid directory documents.  (Currently, the
only ones where this matters for are consensus documents and
authority certificates.)  A document that is invalid by no more than
these tolerances is not _live_, but it can still be used.

These tolerances serve two purposes:

 * First, they allow clients to run with a little more clock skew
   than they would tolerate otherwise.
 * Second, they allow clients to survive the situation where the
   authorities are unable to reach a consensus for a day or two.

Compare with Tor's REASONABLY_LIVE_TIME and NETWORKSTATUS_ALLOW_SKEW
constants; also compare with proposal 212.

Closes #412.

Tidy up ConfigurationSource a bit

See merge request tpo/core/arti!495