This patch addresses the problems below by detailing the solution below in the
corresponding specifications.

> Taxonomy:
>
> * `A`: The destination node.
>
> * `B`: The source node.
>
> * `R`: The relay node.
>
> * outer connection: The connection from `R` to `A`.
>
> * relayed (inner) connection: The relayed (inner) connection from `B` to
>   `A`.
>
>
> Problems we need to solve:
>
> 1. `B` and `A` need to know which security protocol to use to upgrade the
>    relayed (inner) connection.
>
> 2. In the case of active relaying, `R` needs to know which security
>    protocol to use to upgrade the outer connection to the destination.
>
> 3. `A` should be able to offer different security protocols for the
>    relayed (inner) connection. `A` can use different layer 4 ports to
>    demultiplex security protocols for the outer connection. `A` has no
>    demultiplexing mechanism for the security protocols used for the
>    relayed (inner) connection. Thus if `A` advertises different
>    multiaddresses with different security protocols for the relayed
>    (inner) connection, it has no way to determine which one to use on
>    incoming relayed (inner) connections.
>
>
> We propose two mechanisms to solve the issues above:
>
> 1. We have to somehow embed both outer and inner security protocol in the
>    multiaddr. What we could do is introduce another separator, e.g.
>    `p2p-circuit-inner` (name yet to be determined).
>
>    * **Solving (1)**: A multiaddr for a passive relayed connection could
>      then look like:
>      `/ip4/../tcp/../tls/p2p/QmRelay/p2p-circuit/p2p/QmA/p2p-circuit-inner/noise`,
>      with `noise` being used to secure the relayed (inner) connection. *
>    * **Solving (2)**: A multiaddr for an active relayed connection could
>      then look like:
>      `/ip4/../tcp/../tls/p2p/QmRelay/p2p-circuit/ip6/::1/tls/p2p/QmA/p2p-circuit-inner/noise`,
>      with `tls` being used to secure the outer connection and `noise`
>      being used to secure the relayed (inner) connection.
>
> 2. **Solving (3)**: In order for `A` to be able to advertise different
>    multiaddresses with different security protocols for the relayed
>    (inner) connection, while still being able to choose the right security
>    protocol on incoming relayed (inner) connections, we need to include
>    the security protocol for the relayed (inner) connection in the circuit
>    relay v2 CONNECT message from `B` to `A`.

See libp2p#349 (comment) for details.