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

Adapted to the pcre2 change, and (manually) tested both with and
without jit compilation and various tweaks to trigger both match
and depth limits.

Closes #3658

Before 6014912e, VRE_sub() used an
ovector of size 30, which always containted sufficient space to store
the 10 possible back- references \0 thorugh \9.

Now that we use pcre2_match_data_create_from_pattern() and later
pcre2_get_ovector_pointer(), we only get space for the number of
substrings in the pattern, see pcre2api(3):

	The ovector is created to be exactly the right size to hold
	all the substrings a pattern might capture.

Consequently, we need to check that back references do not exceed the
maximum ovector.

Spotted by: Coverity

When receiving H/2 data frames, make sure to take the advertised content
length into account, and fail appropriately if the combined sum of the
data frames does not match the content length.

The change to VTCP_Check() in 58a21da7
broke expect_close in varnishtest.

In RST, there needs to be an empty line after ::, otherwise the whole
block is interpreted as a normal paragraph where newlines are not
preserved.

Now that VRE is the only regular expression API we use, we can migrate
its backend to pcre2. The existing 'pcre_*' parameters are also renamed
to reflect this migration, and 'pcre_match_limit_recursion' gets special
treatment and is renamed to pcre2_depth_limit.

This creates an additional API breakage in VRE: the `match_recursion`
field in `struct vre_limits` is also renamed. One last breakage is the
removal of `VRE_has_jit` used by only one undocumented varnishtest
feature, and the pcre_jit feature is only used by one test case that no
longer fails.

The pcre jit compilation feature was broken anyway: sealing it at
compile time will not reflect what VRE actually links to. Once we have
a test case needing the jit feature, we can introduce a better API for
that check.

There is one outstanding performance problem, the ovector that was
previously allocated on the stack now needs to be allocated from the
heap. It might be possible to implement a pcre2 context to fix that or
maybe pool them, but for now we have heap allocations on the critical
path. The VRE_sub() function makes sure to make a single ovector
allocation (technically a pcre2_match_data allocation) since it's the
only one guaranteed to loop on a single regular expression for the
`regsuball()` use case.

On the documentation front, the SmartOS installation instructions are
hidden for lack of a pcre2 package.

Closes #3616
Closes #3559