This replaces two almost-identical sets of structs and impls.  More
are on the way, as per
  #447

Since "logfiles: Introduce LogfileListConfigBuilder", this code is in
LogfileListConfigBuilder::build(), which is called by derive_builder's
generated LoggingConfig::build(), and which will add a file context
itself due to the `sub_builder` feature.

So this is otiose.  And, we are about to replace this whole thing with
macro_rules-generated code (which won't do this).

Authority: make v3ident public under experimental-api

See merge request tpo/core/arti!463

Fix typos bothering rust-nightly pipeline

See merge request tpo/core/arti!464

tor-basic-utils: Add RetryDelay::reset test

See merge request tpo/core/arti!467

fix typo in doc

See merge request tpo/core/arti!469

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