This commit implements the $Restrict feature described in
https://github.com/varnishcache/varnish-cache/wiki/VIP4%3A-Restrict-VMOD-function-call-sites
it offers the ability to restrict vmod functions and methods scope so that they can only be called
from limited VCL call sites

ref: https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/syntax-for-issue-forms

the 32bit vtesters did not hit all error paths

also cover the case without a response body and check that we actually
hit the error conditions which we intent to test.

to keep down the number of ephemeral TCP ports used.

Preparing to extend the test with the default vtc log buffer size.

Currently the only possible cause is a workspace_client overflow,
but should v1d ever gain an init callback, that could change.

At any rate the cause is never a workspace_thread overflow.

We only log a Storage record when we successfully create an object, but
there may be no clue regarding which storage backend failed to allocate.
We can infer from stevedore VSCs where allocation failures happened, but
knowing from a VCL transaction which one failed will give a definitive
answer.

This is logged as an Error record, and the existing FetchError record
from VFPs ("Could not get storage") is left alone.

When mgt sends a command to the cache process, whether it is a period
ping or an actual operation, it must complete within cli_timeout. When
the cache fails to meet this requirement, mgt sends a SIGQUIT signal
to the cache process. As a result the cache process MAY dump a core
file for post-mortem analysis.

When the core file is missing we are left to our own devices.

To mitigate this, a new signal handler is added for SIGQUIT, but since
we can't (or don't even try to) guarantee delivery on the CLI thread,
we make a last-ditch effort to forward SIGQUIT signals to properly
panic from the CLI thread. With a regular panic we may get both a panic
report and a core dump.

I didn't add test coverage for this, since we try to avoid intentional
core dumps in test cases with the `no_coredump` feature flag that turns
SIGQUIT into a SIGKILL signal.

Refs #3897

This reverts commit 1a9beb31.

See discussion from #3897.

gets remapped a different place.

(This would be horribly slow to run in production.)

This is useful to test extensions with otherwise unaltered varnish test cases,
for example:

VTEST_VARNISHD_ADD_ARGS='-E/tmp/lib/varnish/vmods/libvmod_slash.so -sfellow=fellow,${tmpdir}/fellow.stv,100MB,1MB,64KB -sTransient=fellow,${tmpdir}/transient.stv,100MB,1MB,64KB' ./varnishtest -i ...

These arguments are added and this injection method does not achieve
its goal in all cases (e.g. for the example it breaks when other
stevedore definitions conflict), but it still reduces the cases
requiring manual intervention substantially.

... that there is no v1l open already for the worker.

This enables the assertion also for use on the backend side.

When we fail a HTTP1 connection via v1d_error(), we write directly to
the file descriptor and thus should assert that there is no V1L (line
handler) open.

We had this check only for two out of the four early returns from
V1D_Deliver().

Dridi/dag tell me that changes.rst is not ready for it.

This reverts commit 10633ae0.

in order to improve references to the documentation.

With this change, VCL variable documentation can be referenced
externally by replacing the dot in the variable name with a hyphen and
use that as a target, for example:

https://varnish-cache.org/docs/trunk/reference/vcl-var.html#resp-filters

Rules:

- only current (VCL >= 4.1) variables gain a target

- if there is a section by the same name as a target, do not change it

- No .* for HEADERS like req.http.*

Notes:

This turned out to be more work than anticipated for presumably a
minor change. First I tried to avoid adding target names by turning
the definition list items into subsections, which, with a simple
change to generate.py, worked ok for HTML, but looked terrible for the
man page, which only has three section levels: The variables appeared
on the same indentation level as the section headers.

So next I tried writing code to perform the change automatically, but
this also turned out to be tedious. So ultimately, I used an emacs
macro with manual polishing and the work was done in minutes.

Code is not always the answer...

switch to --strict == --halt 1

ref: https://docutils.sourceforge.io/docs/user/config.html#report-level

Previously, "HTTP response status" was rendered of a subsection
of "storage", which is wrong, they should be on the same
level, or at least not in that order.

We now use the order = - ~ for section, subsection, subsubsection which
we also use in other places like vcl(7) and which is in line with
the example in https://docutils.sourceforge.io/docs/user/rst/quickstart.html#sections