feat: add smol runtime support with TCP and QUIC transports

[neotheprogramist]

Why

This PR adds support for the smol async runtime as an alternative to tokio, enabling users who prefer smol's lightweight, modular design to use libp2p without pulling in tokio dependencies.

Approach

Followed the existing tokio implementation patterns exactly:

• Added SmolExecutor implementing the Executor trait using smol::spawn().detach()
• Added Smol provider marker type and with_smol() builder method
• Implemented TCP provider using async-io 2.0 for async I/O primitives
• Implemented QUIC provider leveraging quinn's runtime-smol feature
• Added feature flag cascade from top-level libp2p crate

Breaking Changes

None

Testing

# Verify TCP transport
cargo check -p libp2p --no-default-features --features smol,tcp

# Verify QUIC transport
cargo check -p libp2p --no-default-features --features smol,quic

# Verify combined
cargo check -p libp2p --features smol,tcp,quic

Usage

let swarm = SwarmBuilder::with_new_identity()
    .with_smol()  // New method!
    .with_tcp(tcp::Config::default(), noise::Config::new, yamux::Config::default)?
    .with_quic()
    .with_behaviour(|_| MyBehaviour)?
    .build();

Scope

• ✅ SwarmBuilder integration (with_smol())
• ✅ TCP transport (smol provider)
• ✅ QUIC transport (smol provider)
• ❌ DNS transport (deferred - hickory-resolver smol support unclear)
• ❌ mDNS protocol (deferred - requires more complex timer abstractions)

🤖 Generated with Claude Code

[tbu-]

Is there a reason to do this besides "it can be done"? Is there any large project that wants to forgo tokio? What's their reasoning?

[neotheprogramist]

Is there a reason to do this besides "it can be done"? Is there any large project that wants to forgo tokio? What's their reasoning?

I need this for mobile development. Tokio uses its own futures implementation which doesn't integrate well with Swift/Kotlin/Dart async runtimes. Smol uses standard Rust futures, making cross-language FFI much simpler. This benefits the mobile ecosystem broadly.

[jxs]

Hi, and thanks for the interest.

I need this for mobile development. Tokio uses its own futures implementation which doesn't integrate well with Swift/Kotlin/Dart async runtimes. Smol uses standard Rust futures, making cross-language FFI much simpler.

can you elaborate on this? Tokio runs std::future::Future implementations on its executor