Restructuring py-libp2p to be more modular and developer-friendly

[ShadowJonathan]

I'm proposing a plan of refactoring large parts of the current py-libp2p library to be more modular and developer-friendly through 3 ways:

1. Restructure the network/application side to revolve around 3 basic concepts: Transport, Connection, and Protocol.
2. Split functionality into "interfaces" (abstract classes with abstract methods), so cross-library compatibility can work without the two libraries knowing about eachother. (For example, a Protocol could verify that it's working on a secure connection (where one of the parent protocols is providing connections through SecIO, or similar) by simply testing if one of it's parents is a ISecureConnection, which denotes methods to grab the node's verified identity).
3. Split interface from implementation, so that every part of the library that's an implementation (TCP protocol, Multiplexer protocol, SecIO protocol, etc.) implements their interface in a one-way awareness solution (implementation is aware of interface, interface is not aware of implementation)

[ShadowJonathan]

Elaboration:

1: Restructure core concepts resolve around (Transport, Connection, Protocol)

A Transport takes a Multiaddr and dials/generates a Connection.
A Connection handles Protocol negotiation logic. And if required, special write/read logic.
A Protocol writes and reads to the underlying Connection.

2: Split functionality into Interfaces

Through this, the library gets extensiblity and modularity even across different implementations;

• A interface ProvidesTransport exists.
• Once a Protocol (from a random library) has been established, the library will see that the protocol instance subclasses that interface, and add that protocol to a register for it to call upon when needed.
• A multiaddress that this protocol can dial arrives, the library will walk past all registered transports to find one that matches it's protocol, it eventually finds the ProvidesTransport Protocol, and dials the multiaddress through it.

Or another one:

• The popular Multiplex protocol is initiated between a peer, it subclasses ProvidesConnection
• The node needs another Connection to that peer to initiate another Protocol, it goes through an iterator of Protocols that falls back to initiating a new Transport.
• The library finds a Protocol instance that subclasses ProvidesConnection, it asks through that interface for another Connection, the Protocol gives it.

Another one:

• A library's Protocol needs security through peer key verification.
• A decorator function @requires_connection(ISecureConnection) is added to the top of the class, denoting that this Protocol can only be initiated with Connections that subclass that interface.
• A library sees that decorator, and when it wants to initiate the protocol with another node, it'll look for protocols within its registry that subclasses ISecureConnection, and iterate through that subset when connecting to another node before initiating the protocol on that connection.

3: Split Interface from Implementation

Py-libp2p should be a framework that provides developers the tools for as much cross-library integration as possible, and thus it should front it's own packaged implementations apart from it's advertised interfaces.
For example: A developer can require libp2p and libp2p-bluetooth into a project, and not worry about integrating one library with another, as the bluetooth transport automatically gets registered with libp2p on invocation of a single function.

[ShadowJonathan]

(In no way am I saying that these proposed changes are definitive and final, I'm simply opening this for discussion on how to change py-libp2p for the better, and make it open for rapid python development within the libp2p platform and network.)

(Ping for invitation to discussion; @pipermerriam, @mhchia, @NIC619, @ralexstokes, @ChihChengLiang)

[ShadowJonathan]

(Pinging @zixuanzh as well, I can't seem to find an email address anywhere from you)