[RFC] comm API re-design

As you know I've already broken off the comm API for listening sockets.

What remains is the comm API for creating connections. I'm going to
start it sometime soon. Please speak up if you disagree, or have
alternative suggestions.

What I have it in mind is to extend the ConnectionDetails class (CD for
brevity from here) to make it a bit more generic and hold data about
remote-end and squid-end of the connection, with some comm-level flags
about the content.

This would allow us to do a few useful things:
  * comm listening API fills it out and hands it to upper layers (as now
    but with more data and longer lifetime).
  * TLS/SSL operations could be done in the comm layer and the info
    embeded in the CD object. Instead of within each TLS-enabled
    component.
  * NAT and EUI lookups can be done in comm where they belong.
  * CD objects could be kept as-is and attached to running state instead
    of copied.
  * CD objects easily give up data about both ends of a link.
  * callers needing to create a connection need only fill one out like an
    application form and hand it to comm.

This last shows it's real benefit with forwarding:

  * peer selection and outgoing-addr selection can generate a list of CD.
  * connect logic can walk the list attempting to get a success.
  * retries can be a true "retry each possible link N times" measure
    without multiple/single IP DNS results fuzzing some cases.
  * can begin to do true controlled 'resume' on alternate routes.
  * peer and route selection only ever gets done once per request.
  * failover for peers by name can be combined with tcp_outgoing_address
    selection.
  * tcp_outgoing_address can easily become async "slow" category.
  * sslbump can generate a CD for direct TLS connect and one for CONNECT
    re-wrap fixing the sslbump failover bug.

Amos

-- 
Please be using
   Current Stable Squid 2.7.STABLE8 or 3.0.STABLE25
   Current Beta Squid 3.1.0.18