They can be stored directly in the sock_opts array or on the stack.

Conflicts:
	bin/varnishd/cache/cache_acceptor.c

The sess and listen_sock structs contain everything we need to find or
infer the former `sock`, `uds` and `force` arguments. In particular, it
helps distinguish between working on a connection vs listen socket.

And conversely rename `to` variables to `so` for consistency.

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

Conflicts:
	bin/varnishd/cache/cache_acceptor.c

It is a 1:1 mapping with IPPROTO_TCP, so TCP_NODELAY was moved down to
be with the other IPPROTO_TCP options.

Conflicts:
	bin/varnishd/cache/cache_acceptor.c

Make a note in the documentation of CLI Command File that it is necessary
to include an explicit 'vcl.use' command in the script.

Limit the selection of the active VCL from MGT's view point to be the last
startup VCL given. That would be the VCL from the very last -f argument
given to varnishd, or the autogenerated VCL from the -b argument (-f and
-b are mutually exclusive). Because all startup VCLs are always set to
state AUTO, and AUTO VCLs are made warm when the child is not
running (which it is not at the time the startup VCLs are compiled), this
ensures that it is a warm VCL that is selected as the active VCL.

With this patch, VCLs loaded through the use of an initial CLI command
script (-I option) will not cause a VCL to automatically be selected as
the active VCL. Rather, it is expected that the initial CLI command script
should have an explicit 'vcl.use' statement to select the active VCL. When
an active VCL is not set, attempts to start the child will fail, which
again will fail the varnishd daemon startup (unless -d is given) with an
error code.

The behaviour prior to this patch when using -I, -f '' (empty field), -F
or -d was not well defined. The first VCL loaded (either by -I startup CLI
script or a CLI 'vcl.load' command) would become the active VCL, even if
that VCL is loaded cold. That is an illegal state and would lead to
asserts. It is also not very useful functionality, given the typical use
case for -I is to set up VCL labels. Those require the tips of the VCL
tree dependency graph to be loaded first, and then the VCLs that selects
the label. This means that the active VCL will typically be the last VCL
loaded, which then will require the use of a 'vcl.use' statement in the -I
script anyways. This makes it an acceptable change of default behaviour
that should not affect users.

mgt_new_vcl() now returns a pointer to the newly compiled VCL program, or
NULL on failure.

This also fixes a wrong return value used previously which would cause a
"VCL compiled.\n" to be output to CLI when the child is not running even
when the VCL compilation step failed.

mgt_has_vcl() now returns an error string describing why it doesn't have a
valid VCL.

This is taken from #3711 by @bsdphk

It is very easy to confuse the child process' vcl_active and the
management process' active_vcl variables.

Rename mgt's active_vcl to mgt_vcl_active, following the naming scheme
used elsewhere.

Add a ASSERT_VCL_ACTIVE() macro that asserts that vcl_active either is
NULL or points to a VCL that is warm.

Sprinkle this macro in the various calls throughout the child process that
are involved in VCL handling.

Patch by: @alveelde

Do not select the first VCL present as the active VCL in the child
process. Instead it should always use what the mgt process tells it
through the explicit 'vcl.use' commands it will send.

Previously, the child could select a cold VCL as the active VCL if that
happened to be the first one present to it during restarts. This could
lead to asserts as that is not an allowed state.

Using the wrong list variable would cause the dependency check to consider
VCLs that were not attempted discarded.

Fixes: #3734

For the REGEX type, we now peek ahead after the first CSTR token if a '+'
operator follows and, if yes, create the pattern as a concatenation.

Fixes #3726

Conflicts:
	bin/varnishtest/tests/v00022.vtc

As a follow-up issue from #3719, it was noticed that dynamic calls to
built-in SUBs did not work.

This issue was caused by more (struct symbol) members missing
initialization in VCC_New().

In turn, it became apparent that the evaluation context check in
vcc_expr5() as tested in v00020.vtc only worked by accident, and only
for built-in subs because (struct symbol).eval was NULL for built-in
subs.

We fix SUB type expression evaluation with a type specific evaluation
function which allows expression evaluation from explicit SUB contexts
only.

Fixes #3720

vcc_act_call() implements use-before-define semantics. To do so, it
needs to instantiate SUB symbols if they do not exist.

However, it wrongly called VCC_GlobalSymbol() also for existing
symbols, overwriting symbol properties.

In the case of the built-in subs, the symbol's lname (historically)
still is the unescaped literal name, while user defined subs have
their name escaped via VCC_GlobalSymbol() -> VCC_PrintCName().

This made the wrong call to VCC_GlobalSymbol() apparent when a
built-in sub was called with an explicit "call" action.

Besides fixing the VCC_GlobalSymbol() call, we also need to set the
lname and rname attributes for built-in SUB symbols initialized in
VCC_New().

Alternatively, we could also have used VCC_GlobalSymbol() there, but
that would have affected other places where we (still) rely on the
known name scheme of built-in subs, e.h. EmitStruct(). While the name
unifaction was nice in general, I found the necessary changes (look up
SUB symbols) not worth the benefit.

Fixes #3719

Fixes #3706

The CircleCI default commit behaviour is changed to package building now
that this is a release branch.

Refs 33ffbbc5

Refs 33ffbbc5

Or when the -p option is used.

Fixes #3687

and sort options alphabetically while being at it.

Relates to ##3687

Spotted by @Algunenano.

To avoid mixing vmod_std coverage with the VMOD feature.