After a cleanup we may still use the request's workspace, so the final
rollback should instead happen at release time before we give the memory
back to the pool.

PAN_dump_struct2() is now renamed to PAN__DumpStruct() following the
guidelines from apispaces.rst in addition to growing a track argument.
This should allow dumping structures that we know ought to be dumped
only once, in case they would be numerous.

There seems to be no good reason to expose it to VMODs yet since they
have no integration point with the panic output, so those definitions
can be confined in cache_varnishd.h for now.

Better diff with the --ignore-all-space option.

In the most common case of a VCL transaction panicking this should only
result in an extra "Already dumped, see above" message, but it may give
more insights for other kinds of tasks.

Getting rid of the very last direct access inside struct ws from
vmod_vtc.

Releasing a reservation or rolling back too early is harmless as long as
nothing is allocated on the workspace that could overwrite its contents.

Once you swap the workspace in its current form with a different kind of
allocator it can turn into effective use-after-free, if rolled back or
released state doesn't linger.

Instead of guaranteeing the pointer alignment of ws->r at the expense of
sometimes reserving more than requested, we can instead drop the pointer
alignment requirement since that does not refer to the beginning of the
allocation.

Instead, it is in WS_Release() that we guarantee that the ws->f remains
aligned for the next allocation. And WS_Release() already did that so we
might as well avoid the potential overcommit from WS_ReserveSize().

This is going to be helpful for a workspace emulator, to make sure that
the alignment overhead wouldn't allow off-by-little overflows to sneak
past the address sanitizer. This very change was initially made for a
workspace sanitizer.

It is also a good occasion to make the relevant checks around the ws->r
pointer in WS_Assert().

This change is visible in r03131.vtc that now exhibits this behavior.

Refs #3320

Not even failing to allocate, but outright panicking.

It was unfit for purpose anyway, since it would allow contents past the
front pointer to be referenced. What we are really looking for where
WS_Inside() was used is actual allocations. WS_Assert_Allocated() was
made redundant by this change.

Refs #3320

Signed-off-by: Asad Sajjad Ahmed <asadsa@varnish-software.com>

Trying to unconfuse bmake on FreeBSD:

    make[6]: don't know how to make vsl_glob_test_coverage. Stop

But I can't reproduce it locally with bmake on Linux.

Instead of generating a test script that performs the compilation, we
can give automake a no-op linker command. With that vrt.h is verified
with a simple `make` or `make all` invocation, before `make check` even
kicks in.

Doing it this way also gives applicable warnings like strict-prototypes
a chance to fail earlier.

Refs #3667

One can always run `make -C include/ check VERBOSE=1` for feature
parity, and even get the other goodies from the regular test driver.

It should be more friendly to maintain than a script incrementally
generated by a makefile. Make it responsible for also running
vsl_glob_test without arguments instead of the test driver, and
restore its output. In case of failure, the -x mode should help
figure which vsl_glob_test failed. While at it give the script a
proper shebang.

Refs #3667

Something DNS always breaks when I join a new network.

After 88698015 broke 32 bit, we need to adjust the default(s) which
are special cased for 32 bit in mgt_param.c. Instead of increasing
things, we make sure the old default vsl_buffer of 4k is maintained.

This looks like a copy-pasta or autocomplete mistake.

On many busy production systems, the VSL buffer for transactions often
fills up, triggering a flush to the VSM. If such a transaction takes a
long time, it can happen that the flushed data is overwritten before
the whole transaction completes. The result is that these transactions
are missed by varnishncsa and other tools. Increasing the vsl_buffer
does the trick, at some cost in workspace usage.

The cost implies that one should increase the workspaces, too. Since
the old defaults of 64k each are too low for many common use cases
today, it is natural to increse everything in one patch.

Some test cases have been updated. These are all cases where the
workspaces have been set very low, and to make sure we are still
testing the same regression, the vsl_buffer has been set to the old
default instead of increasing the workspace.

Spotted by flexelint.

This is how I found the accidental bug fix for #3662:

    git show varnish-6.0.8:bin/varnishtest/tests/c00053.vtc >bisect.vtc
    tools/vtc-bisect.sh -g varnish-6.0.0 -j32 -i

I hope this will help others, I use this script whenever the cause of a
failure is not obvious.

Spotted by flexelint.

Do it on demand, so start/stop changes to available commands is properly reflected.

Fixes: #3642

We need to ensure that vmods use the same functions and data
types as varnish-cache.

Also it seems that having the define in autoconf might suggest
that it could be changed, which would be misleading.

For now, this is only VRE_unpack() to get the pcre2_code handle.

If we ever change the regex backend again, we will remove
vre_pcre2.h and add something else.

Suggested by Dridi, thus authorship attributed to Dridi.

Refs 31e3895a