Fixed on_unsupported_protocol tunnel action (#339)

Fixed on_unsupported_protocol tunnel action (#339)

Instead of tunneling traffic, a matching on_unsupported_protocol
"tunnel" action resulted in a Squid error response sent to the client
(or, where an error response was not possible, in a connection closure).
The following three cases were fixed:

    * port: http_port (real CONNECT)
    * ssl_bump action: client-first or step1 bump
    * handling phase: parsing TLS client handshake
    * expected data: TLS Client Hello

    * port: http_port (real CONNECT)
    * ssl_bump action: client-first or step1 bump
    * handling phase: parsing the first bumped HTTP request
    * expected data: HTTP request header

    * port: https_port (fake CONNECT)
    * ssl_bump action: any action except terminate
    * handling phase: parsing TLS client handshake
    * expected data: TLS Client Hello

Also, when on_unsupported_protocol was configured, Squid wasted RAM and
CPU cycles to buffer client HTTP requests beyond the point of no return
(i.e., roughly, beyond the first HTTP request on a connection or in a
tunnel), when on_unsupported_protocol settings no longer apply.

Client handshake accumulation is now driven by preservingClientData_. We
set that data member when the connection is accepted (because we may
decide to start preserving bytes right away) and reset it whenever that
decision may change, including when switching to a new protocol inside
CONNECT tunnel and confirming the expected/supported protocol by
successfully parsing its handshake.

Squid does not stop handshake preservation when on_unsupported_protocol
gets disabled during reconfiguration, but Squid will not tunnel
preserved bytes if that happens (and will not tunnel a partial handshake
if on_unsupported_protocol configuration keeps changing).

Also changed how IPv6-based certificates are generated. Their CN field
value is no longer surrounded by [square brackets]. This change was done
to improve Squid code that had to be modified to fix
on_unsupported_protocol. It affects certificate cache key so old
IPv6-based certificates will never be found (and will eventually be
purged) while new ones will be generated and cached instead. We believe
these IPv6-based certificates are rare and untrusted by browsers so the
change in their CN should not have a significant affect on users.

This is a Measurement Factory project.