We need this now that we check for contributory behavior.

Now that we have two kinds of isolation tokens (those set on a
stream, and those set by the stream's associated TorClient), we
need a more sophisticated kind of isolation.

This fixes the bug introduced with the previous commit, where
per-stream tokens would override per-TorClient tokens.

When two TorClients are isolated, their streams shouldn't share
circuits, even though they share internal circuit and guard state.

Closes #202.

(This appears to be the emerging consensus of how to handle
RUSTSEC-2020-0159.)

(This appears to be the emerging consensus of how to handle
RUSTSEC-2020-0159.)

Solves a name conflict with the existing tor_client create.

Closes #130.

Closes #200

Signed-off-by: David Goulet <dgoulet@torproject.org>

Previously our code would clear the 'pending' flag on a consensus
only when a _downloaded_ md made it become usable.

Closes #199.

The futures::lock::Mutex was unnecessary, since we never held it
when we were suspending.

This is a big change, but it does simplify the type of Builder a
little, and isolates locking across different (potential) timeout
estimator types.

It's useful to know now only if we now have the lock, but also if we
just got it for the first time.

(One represents code that I forgot to write.)

eta authored 3 years ago and Nick Mathewson committed 3 years ago

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