feat: replace ProtocolName with AsRef<str>

[thomaseizinger]

Description

Previously, a protocol could be any sequence of bytes as long as it started with /. Now, we directly parse a protocol as String which enforces it to be valid UTF8.

To notify users of this change, we delete the ProtocolName trait. The new requirement is that users need to provide a type that implements AsRef<str>.

We also add a StreamProtocol newtype in libp2p-swarm which provides an easy way for users to ensure their protocol strings are compliant. The newtype enforces that protocol strings start with /. StreamProtocol also implements AsRef<str>, meaning users can directly use it in their upgrades.

multistream-select by itself only changes marginally with this patch. The only thing we enforce in the type-system is that protocols must implement AsRef<str>.

Resolves: #2831.

Notes & open questions

This is an alternative to #3745.

I am hoping that with this change, users will already accustom to use the StreamProtocol newtype. Regarding #2863, I think it makes the most sense to remove all these traits in one go and directly have the handler return a list of StreamProtocols.

Dependencies

• fix(gossipsub): always honor support_floodsub setting #3837
• refactor(core): remove EitherIter #3841
• refactor(core): remove InfoIterChain #3842

Change checklist

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

[mxinden]

@thomaseizinger updating https://github.com/mxinden/kademlia-exporter/ right now. Was it a deliberate choice to not implement TryFrom<String> for StreamProtocol? If not, I would create a pull request.

[thomaseizinger]

@thomaseizinger updating https://github.com/mxinden/kademlia-exporter/ right now. Was it a deliberate choice to not implement TryFrom<String> for StreamProtocol? If not, I would create a pull request.

The need to abstract over the creation of StreamProtocol didn't arise so I never thought of it.

What is your usecase? Why can you not use the existing, much more descriptive constructor?

[mxinden]

A user can provide a stream protocol name via a configuration file. I am parsing the stream protocol name as a string and would like to call protocol_name.try_into.expect("something").

What is your usecase? Why can you not use the existing, much more descriptive constructor?

Works as well. Just a bit more verbose.

[thomaseizinger]

I am parsing the stream protocol name as a string

Perhaps FromStr is what we need?

What is your usecase? Why can you not use the existing, much more descriptive constructor?

Works as well. Just a bit more verbose.

A matter of taste for sure, feel free to send a PR! I tend to avoid calling conversion functions explicitly because they are mostly noise.