Bug #14: connection setup may look like syn flood attack if server is

Bug #14: connection setup may look like syn flood attack if server is
refusing connection

If the contacted server refuses connection then the repeated attempts to
connect to the server may look like a syn flood attack. This patch makes
Squid behave a little friendler in such case and:
 * Delays a little between the repeated attempts. Longer if the attempt
was to an origin server.
 * Limits origin server attempts to 3 connection setup attempts or 2 request
forwarding attempts (was 10 on both which only makes sense in peering
relations)
 * Changes the default for maximum_single_addr_tries to 1 as there is plenty
of reforwarding attempts done by Squid and at least 3 attempts to initiate
the request which makes this directive redundant.
 * removes a redundant lock from commConnect*() (cbdata managed)
 * Adds a small delay to commConnect() reconnection attempts when the
contacted destination has more than one IP address or
maximum_single_addr_tries is used.
 * Small cleanup in how/when digest considers a peer usable to not disturb
the peer probing.
 * Cleanup of peer TCP probing to correct timeout management etc and to
more promptly recover after a failure.