My intention behind c021fbca was that
flexelint complains about symbols being defined multiple times.

Yet when we omit all vmods, we end up with lots of 759 (could be moved
from header to module).

So add back vmod_debug and have that refer more of the API.

Without BUILT_SOURCES, we need explicit dependencies

Now that all VMOD sources are prefixed consistently we no longer need to
maintain the lists manually.

We no longer need a special per-VMOD case since we now have one unified
VMOD test suite.

This will improve the build parallelism, and will allow us to run the
VMOD test suite after the main one.

Anything left that would prevent two VMODs to live in the same $(srcdir)
because it would be defined more than once.

Incidentally, defining the variable in the boilerplate makes the
boilerplate unusable out of tree since it assumes vmodtool is in
$(srcdir) which is a show stopper for third party VMODs.

In practice, we only tweak vmod_debug's build for coverage purposes.

Another option could be to have a VTC running vmodtool.py with various
VCC inputs but we currently don't have test coverage for our python
scripts.

That will hopefully not break macos this time.

Refs 8b791930

We can't have more than one test suite if we put all VMODs in the same
directory.

This would otherwise prevent VMODs from leaving in the same directory.

(Spotted, in a round-about way by: Gcc on SunOS)

Now the TCP|UDS simply returns a conn_pool, which then becomes
the primary handle.

cache/cache_vrt.c  916  Warning 438: Last value assigned to variable
'berr' (defined at line 849) not used

berr is intentionally NULLed to clarify that no dynamic value must stay
alive after the BAN_Abandon()

Ref 6eee0074

Ref
https://github.com/varnishcache/varnish-cache/pull/3486#issuecomment-754019262

roadmap:

 v/ add std.ban*(),
    add implicit import std
    vcc aliases ban() to std.ban() (some concerns raised)
 v/ deprecated ban() without std.
    remove ban() without std.

from
https://github.com/varnishcache/varnish-cache/pull/3486#pullrequestreview-561662742

as that ticket is closed now

The ban() vcl action adds bans like the ban CLI command, but has no
facility for in-band error reporting. Errors are only reported to VSL.

We add std.ban() as a replacement for ban() with identical semantics,
but returning if the ban was successfully added.

std.ban_error() is added to report the error, if any.

We add v00009.vtc mirroring v00011.vtc, but with std.ban() replacing
ban(). The test number was chosen to fill a gap close to v00011.vtc.

Implementation:

We change VRT_ban_string() to return any error or NULL for
success. Where the error is not a constant string, we need to format
it on the workspace. For workspace overflows, we need to fall back to
canned constant error strings to ensure that the error case never
appears as success.

Pull out determining the privs head

Re-use will come with a PR

pointed out by Dridi in #3486

introduced by /me in 6cf1138f