Not doing anything for the -C case, since even FREE_OBJ was omitted. Do
we care since varnishd immediately exits once -C is done?

Refs #2232

When postponing,

- re-create the Expect header for pipe mode

- For synth content, close the connection by default, but allow
  VCL to veto this behavior

Prevent drain-reading the body if the connection is closed anyway
Respect Connection: close from vcl_synth

- when we already started reading the body
- for HTTP Versions less than 1.1

whichever comes first

Also log such resposenses

A case probably overlooked in d306f91c and something that needs some
pondering.

It begs a question: why didn't it fail?

Fixes #2203

It shares a lot of parsing infrastructure with log records, but doesn't
support the taglist syntax. Only a verbatim `vxid` token can be used as
the LHS, and only integer operators are supported.

	sub vcl_backend_response {
                return (pass(2s));
        }

It uses `explicit_bzero` when available and falls back to `memset`
otherwise.

New semantic patch, follow-up to 6db7d750:

    @@
    expression fd;
    @@

     closefd(&fd);
    -fd = -1;

Spotted by phk.

Introduced in 7c9916a6, its precise syntax got lost in polishing.

This patch was created using Coccinelle and the following steps:

    $ cat >closefd.cocci <<EOF
    @@
    expression fd;
    @@

    - AZ(close(fd));
    + closefd(&fd);
    EOF
    $ spatch --dir . --in-place --sp-file closefd.cocci

Please note that one use of AZ(close(...)) couldn't be moved to
closefd() because of a const qualifier. There are other calls to
close(2) that are currently not checked on purpose. They may need
to be revisited.

See: git grep -F '(void)close'

Originally from #2145

Originally from #2145

This reverts commit 95d8b34e, this
symbol is not "old".

Refs #2142 #2145

It could also probably be improved further, we've been detecting python
_after_ looking for python-based tools rst2*. Or we can keep unrelated
checks, I don't think it hurts.

The fundamental problem still exists, in that we have no way to
tickle the threads stuck in accept(2), so for now this remains
a debugging feature.

If this (=c00080.vtc) explodes on some platform, start looking
at the Waiter_Destroy() implementation.

a29fca70 requires subprocess.check_output
which was added with Python 2.7