To potentially emit VCL_trace VSL records, we called VPI_count() from
VGC for, in the extreme, every line of VCL.

For a normal setup, VPI_count() would call into VSL only to find out
that VCL_trace is masked and not have any effect.

Issuing two additional function calls for each line of VCL obviously
is something we should avoid unless there is a real benefit.

To avoid the overhead, we move the check for the tracing flag to VGC
and decorate it with UNLIKELY(), which has no effect for now but is
expected to become a branch prediction hint soon.

This should bring the cost down close to zero.

Being at it, we also add VCL control over tracing through req.trace
and bereq.trace. req.trace gets initialized from feature +trace, and
bereq.trace inherits the value from req.trace. For now, tracing of the
housekeeping subs vcl_init and vcl_fini can only be controlled through
feature +trace.

not yet complete, I just had this change locally and want to avoid
repeating work on it.

Forgot to update the doc after changing scopes names to vcl_*

... and use the pedantic VDP to test that we do.

This should plug some less relevant memory leaks from VDPs which
allocate heap memory.

Note that we should not close VDPs for the happy path to allow
transports to keep them open until after cnt_transmit returns (e.g. in
vmod_pesi).

Calling VDP_Close() from cnt_transmit() avoids repetition for error
handling in transports.

The VDP now registers a PRIV_TASK to ensure that. The VDP fini method
is to be called before the task ends, so the priv_task fini method
checks that it ran.

When asserting that the context is a specific sub, we can compare equal.

Ref 478e310a

to facilitate custom filter parametrization

This requirement was dropped in the updated rfc 9113.

Fixes: #3911

Both $Functions call VRT_purge which fails if not called from vcl_hit
or vcl_miss

Since all functions of vmod_proxy use ctx->req, they should then be restricted to client context only

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.