Adding QualityTransport interfaces.

[Jorropo]

Content

Using type casting in go-libp2p and go-libp2p-swarm this change will be seem less to users and subsystems (except maybe for more stream reset due to OnBetter events).

I chose to not go with the event bus because that would require freeing some things myself while with a simple callback I can just let the garbage collector taking care of that.

I also first though of allowing transport to returns quality only when the conn is been made but I abandoned the idea because forcing to return a score allows to check if starting this dial is gonna be beneficial (when we already have a connection) and could other dial can be canceled (e.g. QUIC returning before TCP will cancel TCP's context).

See libp2p/go-libp2p-swarm#162.
Needed by libp2p/go-libp2p-swarm#167.
This doesn't include any change to Secure interface, I'll take care of them later.

[Jorropo]

/cc @raulk @Stebalien (sorry for ping, I have not the right to request review).
I'm now in polishing state (testing, readding limiter, logging and events and cleaning up older unused code) on my way to rewrite dialling, I'd would like to have your opinion on the interface.

[raulk]

@Jorropo thanks for the ping and the contribution. The core team is massively sprinting to meet deadlines for some critical workstreams. It will be a while until someone can properly review these contributions. We will eventually get to it, but right now we’re swamped and I just wanted to warn you.

If you need to use the Quality Transport downstream immediately, I’d like to point you at go.mod replace directives as a mechanism to map an import to a repo of your choice.

[Stebalien]

I'm now in polishing state (testing, readding limiter, logging and events and cleaning up older unused code) on my way to rewrite dialling, I'd would like to have your opinion on the interface.

As a general contributing guideline: for large changes like this, please wait for the design discussions to complete before jumping into implementation work unless you're actually planning on maintaining a fork indefinitely. The core libp2p team is likely to give extensive feedback and final designs rarely resemble initial proposals.