Allow gossipsub Topic construction from any string

[mzabaluev]

Extend the constructor to allow any Into<String> input.
Unfortunately, this invalidates the current call sites with "blah".into(), so this should only be rolled into a new 0.x release.

[mxinden]

I am fine either way as both reveal that an allocation is needed.

@AgeManning what do you think?

[AgeManning]

Hey, yep, I have noticed this.

I've started on gossipsub 1.1 (have had other things come up, but will get back around to it soon). In that update, I've modified the topics to be a bit more ergonomic, so have also addressed this. See for example: sigp@238e305#diff-e508e1fe2df1aa713d7d22989bd2b1a8

I'm happy with this change, but potentially we may re-address with the gossipsub 1.1 update (which should be soon, order of weeks, I promise).

Depends on when you need it @mzabaluev. If you can wait for the 1.1 update, we can roll it in and can have your input on how you would like the topics to be handled there.

[mzabaluev]

Thanks, @AgeManning, I'm looking forward to gossipsub 1.1!

This PR is just a quality-of-life improvement, it's in no way critical for me.

[AgeManning]

If that's the case, I suggest we do all the commits into the 1.1 update, save multiple releases.

I'll ping you when I make the PR to master and get your input on the topics, if that works for you.

I'll leave it up to @mxinden to either merge this in for the time being or defer to the 1.1 update

[mriise]

@AgeManning though a bit off-topic (similar vein), would it be possible to implement multihash (and potentially multicodec) digests of strings instead of strictly SHA?

[AgeManning]

@mriise - We can. The issue is interoperability. Waaay back, Rust used hashing and the go (spec) implementation didn't. See this issue: #473

I think go now has configurable hashing (although I had a quick skim and couldn't find it). The current hash implementation was ported from the old version and is not interoperable (I only included it as an alternative as it was ideally the "correct" way of doing topic subscriptions).

If we added multihashes then only the rust implementation would be able to communicate (potentially other clients could subscribe to the topics by supplying the resulting hash).

I think this is more of a spec issue. If its important I could probably add it in as a configuration parameter, but it should probably be raised as an issue on the libp2p specs repo. If it get's spec'd then all libp2p implementations should implement it.

An alternative way would be to implement it at the application layer. And use the resulting topic hash as a topic "string".

[mxinden]

@mzabaluev I am closing here as it seems to be not-critical and already included in the 1.1 effort of Age. Feel free to ping me in case you would still like to have it included earlier.