The only way to get a SecureDir is by having checked a directory.
Once you have one, it encourages you to open and create files and
directories with the right permissions, and checks them for you.

Also, explain _why_ this is pretty important.

This crate is meant to solve #315 by giving a way to make sure that
a file or directory is only accessible by trusted users.  I've tried
to explain carefully (in comments and documentation) what this crate
is doing and why, under the assumption that it will someday be read
by another person like me who does _not_ live and breathe unix file
permissions.  The crate is still missing some key features, noted in
the TODO section.

It differs from the first version of the crate by taking a more
principled approach to directory checking: it emulates the path
lookup process (reading symlinks and all) one path change at a time,
thus ensuring that we check every directory which could enable
an untrusted user to get to our target file, _or_ which could
enable them to get to any symlink that would get them to the target
file.

The API is also slightly different: It separates the `Mistrust`
object (where you configure what you do or do not trust) from the
`Verifier` (where you set up a check that you want to perform on a
single object).  Verifiers are set up to be a bit ephemeral,
so that it is hard to accidentally declare that _every_ object
is meant to be readable when you only mean that _some_ objects
may be readable.

Replace much handwritten config code with use of derive_builder

See merge request tpo/core/arti!462

Replace handwritten builder struct, accessors, and builder function.

Replace handwritten builder struct, accessors, and builder function.

In
  tpo/core/arti!462 (comment 2797697)
we decided not to do this.

However, having looked again at the way the FallbackList works, I
think there is a lot of value in making these two things (and anything
else like them[1]) as similar as possible.

[1] At least PreemptiveCircuitConfig.initial_predicted_ports and
NetworkConfig.authorities need the same treatment, and perhaps also
GuardUsage.restrictions (although there is no
GuardRestrictionBuilder).

In the irc discussion I imagined `LogfilesConfigBuilder` as opposed to
`LogfileConfigBuilder` (differing only in the `s`) which would be bad,
but we can use `List` instead.

We do *not* need to abstract away the validated version of the config.
Providing a type alias helps the derive_builder sub_builder DTRT
without needing special overrides.

I have split this commit so that we can drop it, if we conclude it's
not wanted.

Change LoggingConfigBuilder to contain Vec<LogfileConfigBuilder>,
not Option<Vec<LogfileConfig>>.  That makes it sane to Deserialize.

Replace LoggingConfigBuilder's file(Vec<>) setter with the methods
discussed in
  tpo/core/arti!462 (comment 2797697)

It's a plural, and that fact is going to be exposed via serde, if it
isn't already.

Now the network fallbacks configuration wants to Deserialize
a Vec<FallbackDirBuilder>, rather than validated Vec<FallbackDir>.

Methods on FallbackListBuilder are as per
  tpo/core/arti!462 (comment 2797697)
mutatis mutandi for the fact that this struct has only fallbacks in it.

This is where the FallbackList type is.  We are going to want to
provide a builder too, which ought to impl Default.

This means that the default value for the type must be next to the
type.  In any case, it was anomalous that it wasn't.

This commit is pure code motion.

We are going to be using sub-field builders.

This commitid is the current head of my MR branch
  https://github.com/colin-kiegel/rust-derive-builder/pull/253
  https://github.com/ijackson/rust-derive-builder/tree/field-builder
Using the commitid prevents surprises if that branch is updated.

We will require this newer version of derive_builder.  The version
will need to be bumped again later, assuming the upstream MR is merged
and upstream do a release containing the needed changes.

We will need the new version of not only `derive_builder_core` (the
main macro implementation) but also`derive_builder` for a new error
type.

Fix typos

See merge request tpo/core/arti!461

Keep http in license text.

Typos found with codespell.

Remove obsolete files from our state directory.

Closes #282

See merge request tpo/core/arti!457

Rename "deletable" to "obsolete".

Simplify function structure.

Report errors from `metadata()` and `modified()`.

Don't claim that we're going to delete something unless we are.

Comment about making CUTOFF configurable.

Report skew estimates from arti-client

See merge request tpo/core/arti!455

This patch removes files created by older versions of arti, if they
are at least 4 weeks old.

Closes #282

Fix typos

See merge request tpo/core/arti!453

circmgr: back off on preemptive circuits if they fail consistently

Closes #437

See merge request tpo/core/arti!456

Rather than running preemptive circuit construction every 10
seconds, we change it to back off when it is "failing".  (We define
"failing" as creating no new circuits, and as giving at least one
error.)

This change means that we'll have one less reason to hammer the
network when our connectivity is failed for some reason.

Closes #437.
Part of #329.

Now that we have TaskSchedule, we don't need to expose these any
longer.

This feature is similar to ChanProvenance from ChanMgr, except that
we don't yet need to report it outside the crate.  I'm going to use
it to distinguish newly created circuits from existing circuits in
the preemptive circuit builder.

(Also, blame clock skew when it is an explanation of why we cannot
finish a connection.)

Instead of just having a function that recalculates the latest clock
skew, instead recalculate the clock skew when it may have changed,
and notify other processes via a postage::watch.

guardmgr: fix a unit test panic.

See merge request tpo/core/arti!454