Successfully tested with a dummy semantic patch:

    @@
    idexpression ctx, caller;
    @@

    -CHECK_OBJ_NOTNULL(ctx, VRT_CTX_MAGIC);
    +AN(ctx);
     CHECK_OBJ_NOTNULL(caller, DEBUG_CALLER_MAGIC);
    -AN(caller->sub);
    +assert(caller->sub);

I decided to cram all definitions in the existing vdef.h file to keep
our relatively simple setup. We can add more macros as we learn what
coccinelle trips over.

Refs f5b0b201

As I was relying on the lack of -E option to discard another type of
non-ESI sub-requests I recently misled myself with this assumption. It
took me a while to realize that I was also seeing transactions I was not
interested in, corrupting the statistics I was deriving from a log dump.

Now that vmod_pesi [1] sets the precedent, we should expect new types of
sub-requests to materialize and expecting the reason for the transaction
to be "esi" is no longer appropriate.

We could also track this field as vtx::sub_level for example, to make it
available as VSL query LHS operand. The focus here was to adjust the
behavior of an existing feature, not add a new one.

[1] https://code.uplex.de/uplex-varnish/libvdp-pesi

Same thing for Link tags since they share the same parsing code.

After #3515 merge

I do not understand
     Warning 552: Symbol 'vpi_wrk_len' (line 50, file cache/cache_vpi.c) not accessed

It is used for array sizing, so I have silenced the warning.

Now that we have the vpi ref as set by VPI_Count() available via struct
wrk_vpi, we can dump our position in VCL at the time of the panic.

Additional changes:

* move handling info from pan_wrk() to the new VPI_Panic()
* output the source index of vcl sources with the name in
  VCL_Panic()

The additional panic section looks like this:

vpi = 0x7f5478be93b0 {
  handling (VCL::return) = 0x0 (none),
  ref = 6,
  vpi_ref = 0x7f54753fb530 {
    source = 0 (\"<vcl.inline>\"),
    offset = 365,
    line = 20,
    pos = 25,
    src = \"vtc.panic(\\\"Had Panic header: \\\" + resp.ht[...]\"
  },
},

The source line is truncated (and truncation denoted by [...]) if longer
than 40 characters.

If the in-memory vcl data source string looks truncated, tok = "..." may
be output instead of src "...".

to be able to use our standard miniobj facilities on it, PAN_dump_struct
in this case.

As vpi_ref is static const in VGC, there is no real reason for magic
checks other than that.

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