Instead of racily advancing time forward, this commit attempts to rework
how WaitFor works, such that it makes advances when all sleeper futures
that have been created have been polled (by handing the MockSleepRuntime
a Waker with which to wake up the WaitFor).

The above described mechanics work well enough for the double timeout
test, but fail in the presence of code that spawns asynchronous /
background tasks that must make progress before time is advanced for the
test to work properly. In order to deal with these cases, a set of APIs
are introduced in order to block time from being advanced until some
code has run, and a carveout added in order to permit small advances in
time where required.

(In some cases, code needed to be hacked up a bit in order to be made
properly testable using these APIs; the `MockablePlan` trait included in
here is somewhat unfortunate.)

This should fix arti#149.

(One represents code that I forgot to write.)

eta authored Oct 19, 2021 and Nick Mathewson committed Oct 19, 2021

The new `hyper` tor-client example demonstrates integrating arti with the
popular Rust `hyper` HTTP library by implementing a custom Hyper "connector"
(a type that can initiate connections to HTTP servers) that proxies said
connections via the Tor network.

This will let callers use the tokio traits on these types too, if
they call `split()` on the DataStream.

(Tokio also has a `tokio::io::split()` method, but it requires a
lock whereas `DataStream::split()` doesn't.)

futures::io::AsyncRead (and Write) isn't the same thing as tokio::io::AsyncRead,
which is a somewhat annoying misfeature of the Rust async ecosystem (!).

To mitigate this somewhat for people trying to use the `DataStream` struct with
tokio, implement the tokio versions of the above traits using `tokio-util`'s
compat layer, if a crate feature (`tokio`) is enabled.

The three arguments TorClient::bootstrap requires by way of configuration
have been factored into a new TorClientConfig object.

This object gains two associated functions: one which uses `tor_config`'s
`CfgPath` machinery to generate sane defaults for the state and cache
directories, and one that accepts said directories in order to create a
config object with those inserted.

(this commit was inspired by trying to use arti as a library and being somewhat
overwhelmed by the amount of config stuff there was to do :p)

Also, tell the "typos" tool to ignore Cargo.lock.

Previously we'd say that we were "waiting for the other process to
bootstrap" even if it was already bootstrapped: and we wouldn't
actually declare success when it was done.

The `get_relay` function was confusing, since it would return None if
the relay was present, but wasn't actually a guard.  We only used it
in one place, and in that one place we used it wrong, leading to a
panic bug.

Fixes #193.

Thanks to the chrono update, we no longer include an
obsolete/vulnerable version of the `time` crate.  Unfortunately, it
turns out that chrono has the same trouble as `time`: it, too, looks
at the environment via localtime_r, and the environment isn't
threadsafe.

One step forward, one step back.  At least the underlying issue is
one that lots of people seem to care about; let's hope they come up
with a solution.

This seems to fix a bug when running cargo check on netdoc individually.

Reported by @janimo

Now we all both address:port, (address, port), and more.

We also allow SocketAddr and IpAddr, but only via a trait
labeled as "Dangerous".

For now, this avoids having to separately handle
AuthorityBuilderError, DirMgrConfigBuilderError, DownloadScheduleConfigBuilderError,
NetworkConfigBuilderError and FallbackDirBuilderError when anyhow is not
used.

Turn off a clippy warning.

Suggested by @cheako.