this needs to live within the exclusive circle of cache_vcl.h includers, so I
went for cache_vrt_vcl.c just because of the name.

This is the refactoring we agreed on to enable an alternative
implementation of #3454. This PR does not yet introduce the copy
callback needed to add the functionality suggested in #3454.

We replace the .free pointer of struct vmod_priv with a pointer to a
methods struct with callbacks. As of this commit, it only contains
the .free callback renamed to .fini. The purpose of the refactoring is
to allow addition of more callbacks later.

The new struct vmod_priv_methods also contains a .type member pointing
to a string to contain an arbitrary description of the type of data any
priv holds which uses these methods.

Implementation:

relevant changes are in cache_vrt_priv.c and vrt.h, other changes are to
the documentation and bundled vmods.

The implementation is a simple refactoring for indirection of the call
to the .fini callback via the methods structure.

This change also exposed #3385

See #3470 for a suggestion how to get out of this

This reverts commit 5cbb3586.

Flexelint complains that this truncation is suspicious, which is fair.
The pdiff() function allows for a more expressive, and hopefully less
suspicious alternative with a bit of hardening in the process.

This way it can be used almost anywhere in the code base and out of tree,
not just in the cache process. The function was slightly polished after
prior discussions with phk and slink.

stdbool.h gets pulled in indirectly, which defines bool to _Bool.
Since we are not using the bool type here, just undefine it.

Better diff with the --word-diff --ignore-all-space options.

Having now the guarantee that VCL sources are always null-terminated we
can use standard string.h functions to detect long strings. We can also
generalize vcc_decstr() to work with all kinds of strings.

Instead of duplicating the code in 3 locations with slight variations,
encode the specificities of each type of string into a struct and have
one location to parse them.

Bonus deduplication, inline C parsing is identical.

This is loosely inspired by vcl_fixed_token() and we could further
reduce the size of the loop in vcc_Lexer() by extracting more logic.

And with that we know for sure that we always have null-terminated
VCL sources.

For a first byte timeout on a new connection, we emit

	FetchError: first byte timeout

For a first byte timeout being reached on a recycled connection, we
should keep the error message similar.

Ref eecd409d

Dridi, phk and myself all stared at this piece of code and see no issue:
res has been calloc'ed l elements. For any res[i] and res[j] access, i
and j are less than l, respectively. l is not increased after the
initial count of elements in s.

Ref 9947307d

Flexelint error:

                           _
		res[i] = vp;
mgt/mgt_vcl.c  749  Warning 661: Possible access of out-of-bounds
    pointer (1 beyond end of data) by operator '[' [Reference:
    file mgt/mgt_vcl.c: lines 719, 722, 727, 744, 747, 749]
mgt/mgt_vcl.c  719  Info 831: Reference cited in prior message
mgt/mgt_vcl.c  722  Info 831: Reference cited in prior message
mgt/mgt_vcl.c  727  Info 831: Reference cited in prior message
mgt/mgt_vcl.c  744  Info 831: Reference cited in prior message
mgt/mgt_vcl.c  747  Info 831: Reference cited in prior message
mgt/mgt_vcl.c  749  Info 831: Reference cited in prior message

The plain text output is a suitable input for tsort(1), initially
meant to find the correct discard order, I realized that it would
be more reliable to let vcl.discard figure that one out.

It wouldn't really work in my initial scenario:

    varnishadm vcl.deps |
    <filter some VCLs out> |
    tsort |
    xargs -n 1 varnishadm vcl.discard

The filtering part only worked for direct dependencies but we can
have two levels with return(vcl).

I'm keeping this command only for setup analysis, the output can
easily be turned into a graphviz dot file for example.

To put it simply, let's take a simple CLI script:

    vcl.discard vcl1
    vcl.discard vcl2
    [...]
    vcl.discard vclX

We can now achieve the same with a single command:

    vcl.discard vcl1 vcl2 ... vclX

But there is slighty more to it, because vcl.discard operates on both
VCLs and VCL labels, and dependencies can exist between both. So in
addition to operate on multiple VCLs it also does so in the correct
order.

This is going to be useful once vcl.discard can take multiple VCL names
at once.

The first operation consists in checking the ability to discard the
requested VCL, the second part effectively performs the VCL deletion.

closes #3379

avoiding local variables and VPI_BundleStrands()

Fixes #3392

I do not understand the global -esym does not work, but the warning is
definitely bogus, the (unisgned)-1 argument is intentional and a
documented feature.

we see this issue in two places (for libvcc and varnishd), hope this
will silence both

it does not register use via tbl/sess_attr.h

leaving these in the "to be reviewed" section because I am not entirely
sure.

I think these cases are:

- ses_set_attr / beresp_filter_fixed: flexelint bug? Looks like it does not
  register use via macros

- ObjGetU32/Lck_DestroyClass API

- HTTP_IterHdrPack / SYMTAB_NOERR cases we do not want to make static
  by design

Solve comparison between unsigned and -1 by moving a cast to where we need it.

the existing code already implied that a VCL_INT be large enough to hold
uid_t / gid_t.

Ref 31164908

Fixes #3243

we do want to use FLAGX | FLAGY even if zero for clarity

error:

Info 835: A zero has been given as right argument to operator '|'

Another case of struct instance names which we want to have, even though
we do not currently use them.

Yes, we do not actually use the mode name, but we still want to have it
for debugging and clarity.

Info 754: local struct member 'vsc_sf_mode::name' (line 57, file
    ../../lib/libvarnishapi/vsc.c) not referenced

Fixes #3243

We want to avoid unsigned integers for reference counting since they
would hide underflows.

Seeing a test failure on vtest I think there might be a race here that I
hope to make more explicit next time it occurs.