Track dialing progress

[drHuangMHT]

According to the coding guideline:

rust-libp2p/docs/coding-guidelines.md

Lines 304 to 313 in b7914e4

	## Allow Correlating Asynchronous Responses to Their Requests
	In an asynchronous context, it is important to enable users to determine the correlation between a
	response and a previous request. For example, if a user requests two new connections to the same
	peer, they should be able to match each new connection to the corresponding previous connection
	request without having to guess.
	When accepting a **command** that eventually results in a response through an event requires that
	command to contain a unique ID, which is later on contained in the asynchronous response event. One
	such example is the `Swarm` accepting a `ToSwarm::Dial` from the `NetworkBehaviour`.

Shouldn't there be a way to track the progress of a dialing request issued to the swarm? How can you track that request when swarm.dial() returns Ok(()) when the request is accepted?

[thomaseizinger]

The DialOpts you pass in give you access to the ConnectionId. You can then correlate all events to this call to Swarm::dial. Because the same API is used in ToSwarm::dial, we opted to not return ConnectionId because it is information the caller already knows :)

[drHuangMHT]

Why this design when there's no such thing as ListenOpts? I think it's an inconsistency when listen_on gives you the ListenerId upon accepted. Besides, ConnectionId is more of an internal state, so it should be managed, or in this case assigned, internally. It feels like we are managing it externally when we need to get it from DialOpts. Moreover, this can potentially create unused ConnectionId when a DialOpts is built but not used. It is an case that basically never happens and does no harm to the program, but it can lead to confusion with logs in which I would naturally assume the ConnectionId increments continously.
In a word, it makes more sense when Swarm::dial() return Ok(ConnectionId) rather than obtaining it from DialOpts.

[thomaseizinger]

We didn't want to return information from a function that was passed in and we had to create the ConnectionId within DialOpts because it was a requirement to obtain the ConnectionId from a yet-to-be-created connection within a NetworkBehaviour to ensure NetworkBehaviours can learn, which connections they initiated via ToSwarm::Dial.

[drHuangMHT]

which connections they initiated via ToSwarm::Dial.

I see, so it's a problem of the architecture.