transports/tcp: Unify symbol naming

[thomaseizinger]

Description

This follows the effort described in #2217. Instead of exporting one TcpTransport and a TokioTcpTransport, we use the already existing modules to define a Transport type alias.

The recommended way of referencing these new transports from the root libp2p crate is:

1. use libp2p::tcp;
2. Reference transports as tcp::async_io::Transport or tcp::tokio::Transport.

Links to any relevant issues

• All crates should have a consistent API & naming #2217

Open Questions

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

[elenaf9]

👍

[jxs]

LGMT 👍

[elenaf9]

Sorry, two things just came to my mind when I though about following the same naming for the QuicTransport;

1. How will tokio::Transport and async_io::Transport be show on docs.rs if lib::Transport is annotated with #[doc(hdiden)]? I believe if we mark this as hidden user will see the type aliases for each provider, but not be able to the see the public interface of Transport, thus also not what method it has and what traits are implemented on it. Is this correct? if so, I'd be strongly in favor of not hiding Transport.
2. Why are we in general not exporting GenTransport and Provider to the user, if they (for whatever reason) want to implement a custom provider? We already have this abstraction, why not expose it?

[thomaseizinger]

Sorry, two things just came to my mind when I though about following the same naming for the QuicTransport;

1. How will `tokio::Transport` and `async_io::Transport` be show on docs.rs if `lib::Transport` is annotated with `#[doc(hdiden)]`? I believe if we mark this as hidden user will see the type aliases for each provider, but not be able to the see the public interface of `Transport`, thus also not what method it has and what traits are implemented on it. Is this correct? if so, I'd be strongly in favor of not hiding `Transport`.

I am linking to the libp2p_core::Transport trait in the docs. Is that good enough?
I can also add an example on how to use it!

2. Why are we in general not exporting `GenTransport` and `Provider` to the user, if they (for whatever reason) want to implement a custom provider? We already have this abstraction, why not expose it?

We are exporting GenTransport (now called Transport). We have to because "it appears in a public interface". The reason I'd rather like to hide it is because it is completely uninteresting to users IMO. The interesting interface is the libp2p_core::Transport implementation.

Regarding Provider: I'd rather not expose it. If it is an implementation detail we can make changes to it without breaking backwards compatibility. Support for new executors will ideally be upstreamed to us.

[thomaseizinger]

This is what it looks like now:

[thomaseizinger]

I ended up removing the hidden attribute again because I couldn't make it work to show the new function otherwise.

[mxinden]

@thomaseizinger is this ready for another review? If so @elenaf9 can you take another look and check whether your concerns are addressed?

[elenaf9]

Sorry for the delay. LGTM!

[thomaseizinger]

@thomaseizinger is this ready for another review? If so @elenaf9 can you take another look and check whether your concerns are addressed?

Yep this is ready to review. Will fix the merge conflicts.

[mxinden]

As mentioned before, big fan of the first-deprecate-then-remove path now. Thanks for making libp2p-tcp consistent with the recent renames.

I am in favor of merging here. Though I think we should tackle libp2p/test-plans#59 first.