swarm: Split off "keep alive" functionality from `DummyConnectionHandler`

[thomaseizinger]

Description

Previously, the DummyConnectionHandler offered a "keep alive" functionality, i.e. it allowed users to set the value of what is returned from ConnectionHandler::keep_alive. This handler is primarily used in tests or NetworkBehaviours that don't open any connections (like mDNS). In all of these cases, it is statically known whether we want to keep connections alive. As such, this functionality is better represented by a static KeepAliveConnectionHandler that always returns KeepAlive::Yes and a DummyConnectionHandler that always returns KeepAlive::No.

Links to any relevant issues

• https://github.com/libp2p/rust-libp2p/pull/2852: To actually replace "Ping"'s ConnectionHandler with a FromFn ConnectionHandler, we need to decouple the "Keep Alive" functionality from the Ping protocol. If this PR is accepted, I'd send a follow-up to remove the keep-alive functionality from ping in favor of using the KeepAliveBehaviour.

Open Questions

• ~Implementations on () are not as easy to discover. Should we retain DummyBehaviour and DummyConnectionHandler but strip the keep-alive logic from them?~
• ~Should we rename the KeepAlive to KeepAlivePolicy (or something else) to avoid ambiguity with behaviour::KeepAlive?~
• ~Should we strip the keep alive functionality from libp2p-ping as part of this PR or in a follow-up?~

Change checklist

• [x] I have performed a self-review of my own code
• [x] I have made corresponding changes to the documentation ~- [ ] I have added tests that prove my fix is effective or that my feature works~
• [x] A changelog entry has been made in the appropriate crates

[mxinden]

Implementations on () are not as easy to discover.

I have to give this more thought. I agree that it makes it harder to discover. Also I don't find the fact that () implements a dummy NetworkBehaviour intuitive.

Should we retain DummyBehaviour and DummyConnectionHandler but strip the keep-alive logic from them?

I think this is a good idea.

[thomaseizinger]

Should we retain DummyBehaviour and DummyConnectionHandler but strip the keep-alive logic from them?

I think this is a good idea.

I'll progress in this direction then!

[thomaseizinger]

This is ready for another review @mxinden !

[mxinden]

Can you update the pull request description?

[thomaseizinger]

Can you update the pull request description?

Updated. Also added new questions.

[mxinden]

Should we strip the keep alive functionality from libp2p-ping as part of this PR or in a follow-up?

Shall we follow the two step deprecation path as we did in the recent path?

[thomaseizinger]

Should we strip the keep alive functionality from libp2p-ping as part of this PR or in a follow-up?

Shall we follow the two step deprecation path as we did in the recent path?

Yeah that is a good idea!

[thomaseizinger]

This is ready to merge from my end. Feel free to merge in case you want to keep the naming as is or want that to happen in a follow-up @thomaseizinger.

I ended up introducing top-level dummy and keep_alive modules in libp2p_swarm that export both, the ConnectionHandler and the corresponding NetworkBehaviour.

[thomaseizinger]

Changelog and PR description are up to date. This is ready to be merged from my end.

[mxinden]

@thomaseizinger can you take a look at the clippy failure?

error: unused import: `NetworkBehaviour`
Error:   --> examples/ping.rs:44:21
   |
44 | use libp2p::swarm::{NetworkBehaviour, Swarm, SwarmEvent};
   |                     ^^^^^^^^^^^^^^^^
   |
   = note: `-D unused-imports` implied by `-D warnings`

[thomaseizinger]

@thomaseizinger can you take a look at the clippy failure?

error: unused import: `NetworkBehaviour`
Error:   --> examples/ping.rs:44:21
   |
44 | use libp2p::swarm::{NetworkBehaviour, Swarm, SwarmEvent};
   |                     ^^^^^^^^^^^^^^^^
   |
   = note: `-D unused-imports` implied by `-D warnings`

Ah yes, I expected that one to happen eventually. I originally got the warning because https://github.com/libp2p/rust-libp2p/pull/2932 wasn't yet fixed!