Previously, the executor for connection tasks silently defaulted to a `futures::executor::ThreadPool`. This causes issues such as https://github.com/libp2p/rust-libp2p/issues/2230.
With this patch, we force the user to choose, which executor they want to run the connection tasks on which results in overall simpler API with less footguns.
Closes#3068.
Currently, our `NetworkBehaviour` derive macro depends on the `libp2p` crate to be in scope. This prevents standalone usage which forces us to depend on `libp2p` in all our tests where we want to derive a `NetworkBehaviour`.
This PR introduces a `prelude` option that - by default - points to `libp2p::swarm::derive_prelude`, a new module added to `libp2p_swarm`. With this config option, users of `libp2p_swarm` can now refer to the macro without depending on `libp2p`, breaking the circular dependency in our workspace. For consistency with the ecosystem, the macro is now also re-exported by `libp2p_swarm` instead of `libp2p` at the same position as the trait that it implements.
Lastly, we introduce an off-by-default `macros` feature flag that shrinks the dependency tree for users that don't need the derive macro.
Remove the concept of individual `Transport::Listener` streams from `Transport`.
Instead the `Transport` is polled directly via `Transport::poll`. The
`Transport` is now responsible for driving its listeners.
As a listening client, when requesting a reservation with a relay, the relay
responds with its public addresses. The listening client can then use the public
addresses of the relay to advertise itself as reachable under a relayed
address (`/<public-relay-addr>/p2p-circuit/p2p/<listening-client-peer-id>`).
The above operates under the assumption that the relay knows its public address.
A relay learns its public address from remote peers, via the identify protocol.
In the case where the relay just started up, the listening client might be the
very first node to connect to it.
Such scenario allows for a race condition. The listening client requests a
reservation from the relay, while the relay requests its public address from the
listening client. The former needs to contain the response from the latter.
This commit serializes the two requests, making sure, in the case of a freshly
started relay, that the listening client tells the relay its public address
before requesting a reservation from the relay.
Co-authored-by: Elena Frank <elena.frank@protonmail.com>
