Re-design feature sets

[thomaseizinger]

Opening a new issue here to track the proposal discussed in #2146.

cc @mxinden @dvc94ch

Summary

An opt-in based feature design is preferable over the current one due to how cargo's features work (once turned on, cannot be turned off in a dependency graph).

Minimal concrete changes

• No features on by default
• A full feature that activates everything, for ease of transition from the current design

Extended changes (to be discussed)

1. Have a development feature that activates stuff like the development transport (and necessary crates).

The advantage over full with this one is that you can still cut down compile-times for tests but have the convenience of having most things available needed for writing tests.

2. Introduce dedicated executor features: I would like to see dedicated tokio and async-std features exposed by the top-level libp2p meta crate.

These features would:

• Forward to the dedicated protocol crates (i.e. libp2p-tcp/tokio)
• Automatically set the executor accordingly. At the moment, this defaults to a futures-threadpool which requires setting an executor explicitly if the one wants to use tokio, otherwise things are going to not work at runtime. libp2p-swarm could expose a feature per async-runtime that sets these executors automatically to the correct one.

As part of this re-design, we could introduce a more coherent naming. For example, at the moment libp2p-tcp exposes a TcpConfig and a TokioTcpConfig. If we expose executor features, it would be more coherent to name all respective configs after the executor-backend they are based on, i.e. AsyncIoTcpConfig and TokioTcpConfig.

3. Add an ipfs feature that activates ipfs-specific crates, f.e. secp256k1 support in libp2p-core.

[tomaka]

As a note, I think it's not a good idea for a Cargo feature, in general, to change the behavior of the code. Cargo features are only meant to expose additional features, and confusion and issues typically arise when you try to do something more than just that.

[thomaseizinger]

That is a fair point, thanks for bringing this up!

If we want features to only be additive but still allow the user to control the runtime, then I think we may have to force the user to be more explicit about it and stop defaulting to things.

What if passing in an executor is mandatory for creating a Swarm? The argument could still be an Option to express that all futures should be polled on the current thread.

We could offer convenience types to make it really easy to specify any of the popular runtimes:

let swarm = Swarm::new(transport, behaviour, peer_id, TokioExecutor);
let swarm = Swarm::new(transport, behaviour, peer_id, AsyncStdExecutor);
let swarm = Swarm::new(transport, behaviour, peer_id, FuturesThreadpool);
let swarm = Swarm::new(transport, behaviour, peer_id, |f| {
	tokio::spawn(f);
});

These convenience types would be available when the respective feature-flags are set.