Treat connection limit errors as pending connection errors.

[romanb]

Currently connection limit errors emitted by a Pool when the per-peer connection limit is reached are emitted as ConnectionErrors as soon as background task reports the connection as established, i.e. there is never a ConnectionEstablished event emitted in these cases. This is problematic for two reasons:

1. The Network code itself actually relies on an outgoing connection attempt to finish either with PendingConnectionError or ConnectionEstablished, otherwise there may even be a leak of entries in self.dialing which never get removed.

2. It actually was the intention that Network::ConnectionEstablished events are always paired up 1-1 with Network::ConnectionError events (though the latter should probably be renamed to ConnectionClosed). The Swarm relies on this behaviour and maps ConnectionError to SwarmEvent::ConnectionClosed, as well as invoking NetworkBehaviour::inject_connection_closed, which may consequently be invoked for connections for which inject_connection_established was never called.

In summary, the per-peer connection limit is currently not safe to use. These problems are addressed here by having the Pool emit a PendingConnectionError instead when the limit of established connections of a peer is hit, thus moving the ConnectionError::ConnectionLimit to PendingConnectionError::ConnectionLimit.

This was supposedly observed via an underflowing counter in a network behaviour that tracks the number of established connections via inject_connection_established / inject_connection_closed.

I didn't get around yet to write a proper test case for this scenario, which I still intend to do, possibly in a follow-up PR, but since the patch is relatively simple and may want to be released relatively quickly, I'm already opening the PR as-is.

[tomaka]

I would remove this field altogether here, as it is confusing and I don't think it is useful in any way.
It is confusing in pool.rs as well, but it is more tolerable there as this is a more internal struct.

Alternatively, if we leave it, we should clarify exactly in which situations this is Some and in which this is None.

[romanb]

Removing it sounds good to me, I never found it particularly useful.