This is a somewhat obnoxious change in its scope and requirements,
but it makes it easier to understand what the real public and
private parts of our APIs are.
Now that we have MockNetRuntime and MockSleepRuntime, we can use
them to test a channel-builder by replaying the contents of a TLS
stream that it will accept.
These lints force us to declare our exported enums and
exhaustive-looking structs as non-exhaustive (so that we can add to
them in the future without breaking our API) or to explicitly
disable the warning for a given enum/struct (to say that we _intend_
for additions to be a breaking change).
Now other crates don't need any 'ifdef tokio' code, since there
are wrappers that implement 'futures' right.
Technically, the 'futures' traits are in some ways less good than
the tokio ones, but we need a consistent API if we want to support
WASM someday and keep support for async_std. I'd rather hold out
hope for a future version of futures::io working like tokio than to
fix ourselves into the tokioverse forever.
For these, we need to call tor_rtcompat::task::block_on() directly,
since they would crash with tokio enabled. Perhaps down the line we
should look for a better fix here.
This is fairly ugly and I think I'll need to mess around with the
feature configuration a while until we get something that's pleasant
to develop with. This still seems like a good idea, though, since
we _will_ need to be executor-agnostic in the end, or we'll have no
way to handle wasm or embedded environments.
Later down the road, we'll probably want to use futures::Executor or
futures::Spawn more than having global entry points in
tor_rtcompat. That would probably make our feature story simpler.
Tokio is the default now, since tokio seems to be more heavily used
for performance-critical stuff.
This patch breaks tests; the next one will fix them, albeit
questionably.
Nick Mathewson