builtin echo doesn't understand -n ?

Really ?

This is a hard dep iff the svg files need to be updated.

The `held == 0` branch in the Lck__AssertHeld function is *never*
taken and `cache.h` instructs to only use the macro. Being generated
from calling code, the panic message becomes more informative.

Panic messages were up until now not very helpful:

    Assert error in Lck__Assert(), cache/cache_lck.c line 175:
    Condition(ilck->held) not true.

E.g.

and

0 tests failed, 7 tests skipped, 558 tests passed

This could use some tlc but will do it for now.

VCC was silently accepting enum values valid for other arguments
following in the argument list as well as other identifiers in the
argument spec (for example "ENUM"). Consequently, wrong enum values in
VCL were not detected at VCC time and passed to vmod functions, which,
in the best case, would detect the error (and, if following the
varnish good practice, panic on a failed assertion).

This is another forgotten case since the enum list was changed to be
terminated by \1 in a78efad8: vcc_expr
would just loop over the \1 terminator up to the final \0 terminator
at the end of the argument spec.

It's a loose comparison of socket addresses, not including the port
number. But not loose enough to compare IPv4 addresses to v4-mapped
IPv6 addresses.

Fixes #2142

Adapted from an original patch from @michbsd: on top of normalizing the
host header we now have a regular expressions that only match the right
domains and potential sub-domains.

Closes #2140

This should stabilize c00049

Previously, unless HAVE_TCP_KEEP was defined equally for varnishd
and an API client (vmod), the latter used a wrong struct declaration
and, consequently, struct params members were accessed at a wrong
location. This could have adverse effects from reading bogus
values to overwriting wrong parameters or other memory.

For consistency, we keep uninplemented parameters also in the
cli and rst output with an appropriate description.

Setting them over the cli is not an error, but has no effect.

is no longer around.

Fixes #2148.

correct course of action is.

Spotted by VTEST

They live as private macros in varnish.m4, which is now included in the
Varnish build during the autogen phase. This way it is now possible to
dogfood on macros we distribute downstream. Considering how simple they
are, they could be made public macros for the convenience of VMOD or VUT
writers.

We don't need to have the LIBS-saving-dance in configure.ac for every
single dependency.

There is now similar logic in varnishd, but by then it may be
too late already, but that still improves chances for the users.

We don't need AC_PROG_CPP, because we don't use the C preprocessor
standalone for anything.

It's not obvious that anybody needs AC_PROG_MAKE_SET ever, it looks
like a band-aid for some crappy Win98-related tinker-toy-compiler.

Amazing (or not...) that nobody in the autocrap community ever
got the idea to add "What made AC_FOOBAR necessary" explanations
to their documentation or changelogs.

This should stabilize r00962 on Ubuntu and make -spersistent less
useless on same.