So we have it available for Panics in a follow-up commit

(struct vrt_ctx).handling is a special animal: As seen by VGC, struct
vrt_ctx is const (and rightly so), yet VCL needs to have a way to
communicate up to core code the return value from subs.

So, handling was a (non-const) pointer into struct worker. This is all
good and well, with the minor drawback that VMODs would get to see it,
while we should make it very clear that they have to go through
VRT_handling() / VRT_handled() and know the rules (no reset of
handling).

As we now want to move also the vpi count into "the ctx", before adding
another unsigned pointer, we introduce struct wrk_vpi, provided by the
worker, but owned by vpi.

With this change, we thus formalize the vpi count requirement and also
remove the handling variable from vmods' direct line of sight.

This commit comprises the manual changes which either could not be or
were not worth being automated.

The next two commits contain a coccinelle script to do the rest of the
work, and the reult of it.

Add a comment so nobody makes that mistake again.

Also: Dont trust brain to work in heat-wave.

based on my local installation, which is a bit more picky than
the v-c.o one.

I was tempted to declare the parameter _Bool or even include stdbool,
but did not dare to move after having read
doc/sphinx/phk/thetoolsweworkwith.rst again ;)

The input argument assertions and checks in http_hdr_flags() were
misleading and lacking. With this patch it returns (NULL) on either input
being NULL, and also when called with an empty string instead of
asserting.

In http_EstimateWS(), all headers are passed to the http_isfiltered()
function to calculate how many bytes is needed to serialize the entire
struct http. http_isfiltered() will check the headers for whether they are
going to be filtered out later and if so skip them.

However http_isfiltered() would attempt to treat all elements of struct
http as regular headers with an implicit structure. That does not hold for
the first three pseudo-header entries, which would lead to asserts in
later steps.

This patch skips the filter step for pseudo-headers.

Fixes: #3830

The vnum symbols are not exported yet, we will decide on that once we
have a case for it.

Under load, the backend connection may not be back in the pool by the
time the ESI fetch starts.

Also check the expected storage allocation failure happened.

The reason to blindly trust gethostname(3) is that a system returning a
broken host name should not prevent Varnish from starting when there is
no explicit -i option in the command line.

It disappeared from libvarnishapi during the 2.0 soname bump.

Refs 74328de8
Refs 07d4e752

> A proxy MUST send an appropriate Via header field, as described
> below, in each message that it forwards.

See rfc9110/7.6.3.

Change made to the Via header:

    -Via: 1.1 varnish (Varnish/x.y)
    +Via: 1.1 ${i_opt} (Varnish/x.y)

It should actually better serve its purpose of informing about the hops
a request (or in this case a response) went through. This is how Via is
defined in HTTP:

    Via = #( received-protocol RWS received-by [ RWS comment ] )

Using the server identity (which defaults to the server host name) is
more accurate for the received-by field. We still advertise Varnish in
the optional comment field, and hopefully that's what analytics services
rely on to recognize a server as a Varnish instance.

A bit of trivia, a proxy MAY add a Via entry to the response and MUST
add one to a forwarded request: Varnish only adds the optional one.

Refs rfc9110/7.6.3.
Fixes #3794

It can still be overridden with `varnish vNAME -arg`, as usual.

The order for Via entries follows the response return path, from the
furthest proxy to the closest.

Refs #3794

This should remove one error-prone step in the release process.

Better diff with the --word-diff --word-diff-regex='\w+' options.

Refs #3794

It works both with trunk or x.y.z versions, resulting in trunk for the
former and x.y for the latter.

Refs #3831

We have various stat counters for the shared memory log (shmlog),
but nothing to give us the number of bytes used (consumed). The
new shm_bytes counter remedies that.
Signed-off-by: Dridi Boukelmoune <dridi.boukelmoune@gmail.com>

According to the GCC manual on -fno-omit-frame-pointer:

> Note that -fno-omit-frame-pointer doesn't guarantee the frame pointer
> is used in all functions.  Several targets always omit the frame
> pointer in leaf functions.

And what is says about -m[no-]omit-leaf-frame-pointer:

> -momit-leaf-frame-pointer
> -mno-omit-leaf-frame-pointer
>
> Omit or keep the frame pointer in leaf functions.  The former behavior
> is the default.

So we should probably prevent both.

Closes #3831

Required for seamless debugging.

Alternatives considered:
- add vext_so_keep debug flag -> overkill

To decide:
- rename to libso_keep / "Keep copied VMOD/VEXT libraries" ?
  (libso to disambiguate from so for socket option)