Reject directory circuits early if they are too skewed.

Closes #412, #467, and #466

See merge request tpo/core/arti!501

# Conflicts:
#   doc/semver_status.md

This reverts merge request !509

Do backtrace string matching test only on Linux

See merge request tpo/core/arti!509

Ian Jackson authored 2 years ago and eta committed 2 years ago

"Fixes" #455 by suppressing the test.

Fix typo

See merge request tpo/core/arti!510

Abolish arti-config, replacing with tombstone crate

See merge request tpo/core/arti!508

impl_standard_builder: Test the Deserialize impl and have it generate ::builder

See merge request tpo/core/arti!507

Generally, change the paths that mention the crate name to go via a
module-level "use".

This involves adding tor-config as a direct dependency for a few
crates.

This crate no longer has any reason to exist.  All its remaining
functionality is generic enough to go into tor-config.

In this commit, we move the contents of lib.rs into a new file in
tor-config.  It contains:

 * Code motion
 * The minimal "mod" and "use" changes
 * The minimal doc comment
 * A new a compat alias for ConfigurationSources.

The compat alias is there because various crates currently speak of
arti_config::ConfigurationSources and it is most convenient to fix
them up after the type is available in tor_config.

These are needed to support the code which is moving.

That's where this definitions is now.  This test ought to have been
moved in
  Move default_config_file() into arti-client

config load: Move mistrust checking to load()

See merge request tpo/core/arti!504

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.

This deletes many handcoded impls.  It also generates lots of impls
that we previously didn't have.

Test the Deserialize impl of every config struct.

This detects bugs like the one fixed in !502.

The macro now becomes more complex because it needs to take options.
Right now this tt-munching option parser is overkill, but this
leave space for further options in the future.

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.