This anticipates some features planned for 6.0 that are presently
not yet implemented:

- UDS requires VCL 4.1.
- VCL variables local.socket and local.endpoint

On reception of a SETTINGS frame with a new value for
INITIAL_WINDOW_SIZE, we also need to adjust the flow-control window for
any active streams. rfc7540, section 6.9.2

Ref: 63807dd2

Found while working on https://code.uplex.de/uplex-varnish/varnishevent

the section/subsection/subsubsection structure was broken.

Regarding the 304 and beresp.ttl / beresp.grace / beresp.keep I am
missing a fourth level, input welcome.

Feel free to improve further!

in ban_lurker_test_ban() we remove completed bans from the obans list
so the ban list tail might not be present in the obans list.

To ensure that we stop at the tail, we now find our obans iteration
termination ban walking the bans list backwards until we find an
active ban, the head or the first obans element. In the latter two
cases we are done.

If there are any bans left to mark completed, the last active ban must
be contained in the obans list so we should terminate correctly.

Fixes #2556

Closes #2598

Fixes #2597

Merges #2600 slightly modified

depends on the client-varnish connection happening over
127.0.0.1.  Fake it for jails and IPv6-oid hosts.

We introduce a shard_param object to hold the shard director lookup
parameters which until now could only be passed to the .backend()
method.

By associating a parameter object with a shard director, we enable
LAZY lookups as with the other directors. Parameter objects are
defined with VCL scope (normal vmod objects), but can be overridden
per backend request using a task priv.

We use the same concept to carry shard.backend() parameters to
vdi resolve for LAZY mode: They get saved in a per-director task
scope parameter object.

Each object points to another object providing defaults for
values which are not defined.

Actual resolution of the various parameter objects does not happen
before they are used to allow changing them independently (ie,
shard .backend() parameters have precedence over an associated
parameter object, which by itself can be overridden).

Overview of parameter objects (pointers are alternatives)

shard() director	shard_param() object	default praram

	     --------------------------------->	  vmod static
  VCL obj   /				     ->
  .param  -+--------->	  VCL obj	    /  _
  			  .default  --------   /|
					      /
			     ^		     /
			     |		    /
					   /
			  .default	  /
	------------->	  TASK priv	 /
       /				/
  .default -----------------------------
  TASK priv

Properly implementing vmod_storage requires the VMOD to
sanction symbols at VCC compile time, and I'd rather not
face that right now.

Fixes #2596

Spotted by: Dridi

Add assert to make sure it stays that way.

Ref: #2500

see doc/changes.rst for details

Closes #2509

This basically reverts a29fca70,
except that we are using python instead of make-inlined shell code to
do the work.

Reason: vcs_version.h needs to be up-to-date under all circumstances,
otherwise we will end up with wrong version information in binary
builds, which would divert developer resources into unproductive
confusion compensation.

With an all-in-one generate.py, we basically have the choice between:

- running it with each build, which breaks incremental builds as
  generate.py rewrites central includes like vcl.h

- adding version information to all generate.py-build files or similar
  mechanisms to avoid re-writing them unless they have actually
  changed.

- contradicting the argument given above

I think that, unless there are strong reasons for a single
generate.py, avoiding these issues by splitting functions is the best
option.

This got lost with a29fca70

By imposing a fixed ordering on our levels structs, we ensure that pointers
to them are also ordered such that comparing two of them will compare as level
ordering.

Fixes #2587

If the listen() system call were to report problems, they are now reported
back to the management process, failing the child startup (instead of
asserting). This can happen on many widely used Linux kernels if the
listen socket already has another process listening on that port with the
SO_REUSEPORT flag set.

Newer Linux kernels will report the problem at bind() time (causing error
to be reported upon management process startup).

Fixes: #2551