see https://github.com/varnishcache/varnish-cache/pull/3804 for context

The C compiler checks have been removed as they are already
contained in VARNISH_PREREQ

On some autoconf versions (e.g. 2.71 on MacOS, installed with `brew 
install autoconf`), not quoting this argument results in a syntax error
in `configure`:

```
sh configure
# ...
checking for joinable pthread attribute... PTHREAD_CREATE_JOINABLE
checking whether more special flags are required for pthreads... no
checking for PTHREAD_PRIO_INHERIT... yes
configure: line 14927: syntax error near unexpected token `newline'
configure: line 14927: `    '''
```

Adding `[...]` quotes fixes this; see 
https://gerrit.openafs.org/#/c/9995/ for a similar problem in a
different OSS project.

VCL_INT is int64_t, not long. Do as varnish does: cast to `intmax_t`.

It was a mistake to add this change to master, it should only live in the pr3287 branch.

This reverts commit 132b022a.

Closes #2

Ref https://github.com/varnishcache/varnish-cache/pull/3287

- minimum ttl of 10s for HFM objects
- simplify the X-TTL code
- show is_esi() example

this can save calls into the brotli code.

Note: I thought we might be able to avoid the additional ring buffer
copy in the brotli encode by using a buffer of size 1 << lgblock, but the
brotli code calls RingBufferWrite() even if the input buffer holds all
of the data to be compressed.

The corresponding varnish API function arguments are signed, make our
struct match them.

... such that the unix jail is in effect: Then the accept socket is
created as root and vcache:varnish cannot open it for writing

the delay is not an optimal solution, a barrier would be much more
appropriate, but I have not found the right place

The VFP trunk now requires Varnish master since the commit that
changed OF_CHGGZIP to OF_CHGCE.

See the discussion in Varnish issue #2910. A 304 IMS beresp could
(weirdly) set Content-Encoding to something other than the result
of previous VFP filtering, in this case compressing the response
with gzip. Nevertheless, Varnish does the right thing when the
OF_CHGGZIP flag is set.

Set the OF_CHGGZIP flag to indicate that:
- The ETag in a client response must be weakened if the response
  body differs from the fetched response.
- Any Content-Encoding header in the fetched 304 response should
  be removed.