in varnish-cache, access to all ESI sub-requests happens in a single
thread, but vmods (VDPs) may add concurrency.

We thus protect access to PRIV_TOP with the session mutex.

Any vmods using this facility will likely need to add additional locking for
the actual data structures referenced through the PRIV_TOP and any other
access to the top request.

For alternatives previously considered, see #3139

VGZ_NewGzip will either assert or succeed.

Turn assertion into VFP error

The vtc is based upon r02645.vtc and reliably reproduces the panic
without the patch by sweeping through possible amounts of free workspace
ranging from 4 to 400 bytes.

Fixes #3253

After the initial discussion from #3163, and looking more closely at how
variable access is handled in subroutines I noticed a discrepancy.

Setting a read only variable like obj.ttl in vcl_recv would result in
a misleading error message explaining that it is read only, instead of
simply not available.

This change defers the illegal write check, registering unconditionally
that the symbol was used in a set action. As a result we always get the
correct error message but depending on whether this is happening in a
vcl_ or custom subroutine we may either get "in subroutine" or "from
subroutine" in the error message. A minor discrepancy probably worth
getting rid of the prior inconsistency.

This is covered by the v21 test case.

That would be the symbol itself instead of only the relevant mask, and a
XREF constants wrapping the error message as well. The `struct xrefuse`
pun was definitely intended.

Where relevant means the highest verbosity when fields are filtered with
-f on the command line. There is still a caveat that this only applies
for the first iteration, and some parameters may conditionally appear
and not be visible when that event occurs (for example, when the child
process starts).

The rebuild variable was used as a bitmap but did not make use of
individual bits. This is now the case, but only for the two actionable
rebuild conditions.

Closes #2990

Refs #2990

Refs #2990

The plan is to reuse the points window and keep the status window going.

Refs #2990

no semantic changes, just consolidating three places in one

(thus pushed during freeze)

Refs #3251

Not sure I like that everything is a bullet point, but well, someone
else did the dirty work for this release so I'll shut up and roll with
it.

We are finding more flaky tests thanks to them, so for now we prefer to
avoid false positive over slowing down the build.

have seen this failing on Travis with:

**** v1   vsl|       1004 VCL_call        b BACKEND_FETCH
**** v1   vsl|       1004 VCL_return      b abandon
**** v1   vsl|       1004 BereqAcct       b 0 0 0 0 0 0

Tested ok locally with varnishtest -n 1000 -j 60.

As @Dridi rightfully commented via email, the default vsl_mask does not
contain Debug

no, they do not need a Translation Lookaside Buffer

Closes #3237

Refs 0cf29671

Automated with Coccinelle, so the semantic patch could be reused in the
vtest project.

Closes #3238

This reverts commit ac602e01.

@Dridi reminded me that we do not want "trunk" release notes in the 6.4
branch to come.