this would have caught 7395ecae

Other polish.

$Module description, and suggest people to do it that way.

Make reporting syntax errors easier.

This adds rate limiting to varnishncsa and varnishlog.

Rate limiting is done on a per-transaction basis, respective to the
grouping mode selected. I.e. for -g request the limit will apply on a
per-request basis, -g raw on a per-record basis, etc.

Rate limit is specified as -R <limit>[/duration]. Default period if not
specified is seconds ('s').

This adds a ctx->handling test at the beginning of any compound
statement, to catch the cases where VRT_fail was invoked as part of an
if test condition.

Fixes: #2840

This may break out of tree code not respecting include order of vdef.h
first (or via cache/cache.h). It's trivial to fix and forces consumers
to follow the tracks.

Refs #2791

Seen once, and failed to reprocuce (yet), needs to be understood
better

from vmod_blobdigest tests/usage.vtc:

**** v1    1.8 CLI RX|No panic to clear
***  v1    1.8 debug|Info: manager stopping child
***  v1    1.8 debug|Debug: Stopping Child
**** v1    1.9 vsl|          0 CLI             - EOF on CLI connection, worker stops
***  v1    2.8 debug|Info: Child (174227) ended
***  v1    2.8 debug|Info: Child (174227) said Child dies
***  v1    2.8 debug|Debug: Child cleanup complete
***  v1    2.8 debug|Assert error in MCH_TrackHighFd(), mgt/mgt_child.c line 203:
***  v1    2.8 debug|  Condition(fd > 0) not true.
**** v1    2.9 STDOUT poll 0x10
**   v1    2.9 WAIT4 pid=174215 status=0x0086 (user 0.914949 sys 0.567445)
*    v1    2.9 Expected exit: 0x0 signal: 0 core: 0
---- v1    2.9 Bad exit status: 0x0086 exit 0x0 signal 6 core 128
*    top   2.9 failure during reset

On the 6.0 branch the regression appeared in ca76ef57 instead.

Side note

	#define CLOSE_FD_UP_TO	mgt_max_fd

exposes that we are currently missing to track some fds.

The name CLOSE_FD_UP_TO implies that the value is included.

Also this is the semantics of MCH_TrackHighFd() and relevant for
 #define CLOSE_FD_UP_TO mgt_max_fd

Ref 3c0b8768

still have been happening on the workspace (See: VRG)

from the top down.

Conflicts:
	bin/varnishd/cache/cache_req_fsm.c

The conflict was just the result of cherry-picking changes out of order,
nothing to be worried about.

Conflicts:
	bin/varnishd/cache/cache_vcl.c
	bin/varnishd/cache/cache_vcl.h
	bin/varnishd/cache/cache_vrt_filter.c

It was possible to back-port this change without bringing beresp.filters
and changing the VRT interface. So we get the benefits of this change
and more that will follow and leave the possibility to minor-bump VRT to
back-port beresp.filters in the future if that doesn't break.

This clearly breaks $ABI strict VMODs, but that's part of the deal.

Fixes: #2831

Allow calling it for this purpose only (stop asserting if the
temperature has not changed)

The actual benefit of this will be in follow-up commits

Conflicts:
	bin/varnishd/mgt/mgt_vcl.c

Fixes #2835

arguments could leak from one vtc command to the next where NULL
arguments do not necessarily denote the end of arguments, eg. in
varnish_expect

I failed to find any issue in varnish and failed to find a
workaround for the code, so change the test to add an additional
space after the tab-completion.

If anyone has a better solution, please go head. Otherwise I feel
this is not worth any more time.

The test change, though not being ideal, should not cause any
harm at least.

Closes #2833

The fact that a boolean argument is present does not imply
that it's true.

This reverts commit 57cd74cf.

I promise to look after this once I got my Flexelint config back,
which, unfortunately, I lost during a reinstall. Yes, I do have
a backup, but cannot access it easily at the moment.

Conflicts:
	bin/varnishd/cache/cache_req_fsm.c

For backend requests, we do not have the thread local storage of the
client thread available, so trq.req will normally be (nil).

Dump the busyobj back pointers to req/sess/wrk to maximize the
usefulness of panics.

Also reorder the panic by struct busyobj and add some more members
which may or may not be useful (but when we find out, it is likely
too late).

Also move the vmod list dump to the top level.

Noticed when trying to understand if #2667 was also a stack overflow
in the context of #2817

Conflicts:
	bin/varnishd/cache/cache_panic.c