[PATCH] Bug 3478 - re-enable peer selection on traffic with unverifiable Host header

Background:
   This problem only occurs when we are handling an intercepted request
on a TCP connection destined to a machine not listed on the Host header
domains IP address list. To fix this bug properly we are going to have
to wrap untrusted requests in a CONNECT request and pass it to peers.
Who are also going to have to be updated to un-wrap the CONNECT and
treat the internal request as intercepted traffic themselves. This is
turning into a big project all on its own.
  In order to prevent Squid-3.2 taking another year or two, we have
decided to defer the fix to a later Squid series.

The workaround:

This patch re-enables Squid peer selection algorithms for intercepted
traffic which has failed Host header verification.

When host verification fails Squid will use, in order of preference:
  * an already PINNED server connection
  * the client ORIGINAL_DST details
  * cache_peer as chosen by selection algorithms

NOTE: whenever DIRECT is selected by routing algorithms the
       ORIGINAL_DST is used instead.

Peer selection results are updated to display PINNED and
ORIGINAL_DST alongside DIRECT and cache_peer.

SECURITY NOTE:

   At this point Squid will pass the request to cache_peer using the
   non-trusted Host header in their URLs. Meaning that the peers
   may still be poisoned by CVE-2009-0801 attacks. Only the initial
   intercepting proxy is protected.

   Full protection against CVE-2009-0801 can be enjoyed by building
   Squid with the -DSTRICT_HOST_VERIFY compile-time flag. This will
   make the peers unreachable for intercepted traffic where the
   Host verification has failed.

PS. The notion was floated of re-writing the Host header or URL domain
to the original
  destination IP and passing that through. However that method is known
to break
  virtual hosted websites, which unfortunately do overlap a great deal
with the hosting
  companies use of Geo-DNS on their CDNs.

Amos