src/lib: Add libp2p-tls to development_transport

[mxinden]

Once libp2p-tls is no longer an alpha (which it is today, see below) I suggest we add it to our development_transport convenience method.

Thoughts?

rust-libp2p/transports/tls/Cargo.toml

Lines 1 to 6 in 4d1b165

	[package]
	name = "libp2p-tls"
	version = "0.1.0-alpha"
	edition = "2021"
	license = "MIT"
	exclude = ["src/test_assets"]

rust-libp2p/src/lib.rs

Line 182 in 4d1b165

pub async fn development_transport(

[thomaseizinger]

Those functions are problematic IMO, at least how they are currently used (inside tests and examples), see #3056.

I also think the naming is off. "development" to me suggests that this is something I use during testing but not in production.

It also doesn't fit in well with the executor-specific features that we are currently implementing.

I can see a "recommended" stack being useful but then it should be rename and I don't think we should use the recommended stack in tests and examples.

Tests should use a transport as simple as possible (probably memory + plaintext).

For the larger examples, using that recommended transport works because we are already in the libp2p crate. For all other transports, we would introduce a circular dependency again. We can either move those examples or inline it there.

In general, I'd prefer if we make composing upgrades simpler and less verbose so the value of these convenience functions is basically 0 and we don't lose anything from deleting them.

[thomaseizinger]

Tests will eventually use #2888.

For the examples, we could move away from regular cargo examples and instead introduce an examples directory that has multiple crates in it. Those would probably be easier to maintain because they would have the exact same layout as a user's application. We'd just specify only the features we need in them which makes them easier to run too.

[thomaseizinger]

Cross-referencing an idea here: #3635 (comment)

[thomaseizinger]

Closing this in favor of #3657.