Fixes #2386

I don't think it matters anywhere else, but future-proofing is good.

Hopefully fixes #2586

This should help readability of the code, hopefully.

The API remains unchanged.

Local variables for vsl_status are called 'r', variables holding
a VSLQ_dispatch_f return value are called 'i'

Makes it possible to distinguish listeners in a VSL client
transaction. Especially if there is more than one UDS listen
address, since all of them are logged as the bogo-IP 0.0.0.0:0
where addresses are logged.

pipe remains the only exception.

Ref: https://tools.ietf.org/html/rfc7230#section-2.6

   Intermediaries that process HTTP messages (i.e., all intermediaries
   other than those acting as tunnels) MUST send their own HTTP-version
   in forwarded messages.

Closes #2574

Avoid keeping H/2 streams alive indefinitely.

This adds timeouts for:
  - How long we allow a stream to wait for a WINDOW_UPDATE, subject
    to idle_send_timeout
  - Total duration after we started transmitting a response,
    subject to send_timeout

We currently do not make any attempt at sending a GOAWAY or a PING for
client inactivity. This may be something to reconsider at a later point.

In particular H2TxHdr, H2TxBody, H2RxHdr and H2RxBody will now be masked
out by default.

Document workaround for ESI (also works for gzipery).

Fixes #2554

Upgrading to 6.0.

Ref c785de16

Storage defaults to umem where libumem is available, as is usually
the case on SunOS. So checking SMA.* stats was causing the test to
fail on Solaris.

There might be code in vcl_miss changing the request which we don't
run for bgfetches, which could lead to unexpected behaviour.

On the other hand, what purpose does vcl_miss serve? Is there anything
we can do in vcl_miss which we can't do in vcl_backend_fetch?

Some user agents like Safari may "probe" specific resources like medias
before getting the full resources usually asking for the first 2 or 11
bytes, probably to peek at magic numbers to figure early whether a
potentially large resource may not be supported (read: video).

If the user agent also advertises gzip support, and the transaction is
known beforehand to not be cacheable, varnishd will forward the Range
header to the backend:

    Accept-Encoding: gzip (when http_gzip_support is on)
    Range: bytes=0-1

If the response happens to be both encoded and partial, the gunzip test
cannot be performed. Otherwise we systematically end up with a broken
transaction closed prematuraly:

    FetchError b tGunzip failed
    Gzip b u F - 2 0 0 0 0

Refs #2530
Refs #2554

Fixes: #2582

So don't make the test for the error depend on the specific message.

In this case, because getaddrinfo(3) may or may not resolve to a
sockaddr_un for path if it happens to be a socket (it does on FreeBSD,
doesn't on Linux).