We have a dedicated enum entry for that, and nothing prevents the caller
from passing a negative value.

how vcc_expr actually works...

No methods are implemented yet.

get too confusing.

background: When the ban lurker has finished working the bottom of the
ban list, conceptually we mark all bans it has evaluated as completed
and then remove the tail of the ban list which has no references any
more.

Yet, for efficiency, we first remove the tail and then mark only those
bans completed, which we did not remove. Doing so depends on knowing
where in the (obans) list of bans to be completed is the new tail of
the bans list after pruning.

5dd54f83 was intended to solve this,
but the fix was incomplete (and also unnecessarily complicated): For
example when a duplicate ban was issued, ban_lurker_test_ban() could
remove a ban from the obans list which later happens to become the new
ban tail.

We now - hopefully - solve the problem for real by properly cleaning
the obans list when we prune the ban list.

Fixes #3006
Fixes #2779
Fixes #2556 for real (5dd54f83 was
incomplete)

93d80501 made execution of
ban_lurker_test_ban() conditional on bd != b, which effectively caused
objects hanging off bans below request bans to not get tested against
relevant bans.

Because object bans (from the obans list) are being marked completed,
the objects which were skipped would also be missed to get evaluated
against the relevant bans at lookup time unless they were evaluated in
request context. So, in effect, we would simply miss to test bans.

Fixes #3007

Maybe related to #3006

This is not very elegant, but I wanted to maintain the
same error messages for now.  More to come.

Spotted by:	fgs with asan (in the castle)

With this script we can essentially use a VTC to track down a regression
and see what broke after getting a cup of coffee, lunch, or whatever you
wish to do while the script is running.

It will search out of the box for a regression between the last tag and
the current git head, and assumes the last tag passed the test case. It
is otherwise the maintainer's responsibility to provide the good and/or
bad commits beforehand.

For more information:

    tools/vtc-bisect.sh -h

I had this idea after setting up an automated bisect one time too many
for #3003 and decided to generalize this in a handy script.

For example:

    tools/vtc-bisect.sh -b d6d34160~ bin/varnishtest/tests/r03003.vtc

The script works on a best-effort basis and tries to minimize rebuild
time, or broken builds. It has minimal error handling and may leave you
in a dirty git tree stuck in bisect mode as a result.

I also noticed that 6.2.0 was not tagged in the master branch, so the
example above starts with the varnish-6.1.0 tag. Tagging major releases
(aka x.y.0 or dot-zero releases) from master is part of the release
procedure and this facility should give one more reason to enforce the
rule. Last time it happened before 6.2.0 was 5.2.0 so there's clearly
something wrong with x.2.0 releases...

This will of course not solve all bisect problems if for example a VTC
relies on a feature that wasn't available in varnishtest when the
regression was introduced and we still may need to perform manual git
bisect operations but hopefully this should save us time from now on.

with references.

The last three commits already made configure recommend installing
Python 3 packages and look for versioned executables, however with a low
priority.

This is a problem on systems such as OpenBSD 6.5 with a default Python
version at 2.7, where 3.7 flavored Python packages get installed with
a "-3" binary suffix.  That is, when both rst2man and rst2man-3 are
installed at configure time, the lower version will be picked unless
explicitly passed through `--with-feature' arguments.

Regardless of this specific case, trying more specificly versioned tool
names first seems correctly in line with recent development and less
error prone, so change it accordingly.

This reverts commit 86af5ce0.

Unfortunately we have two scopes top and task that may conflict when
esi_level is zero. This restores the id field, making struct vrt_priv
slightly larger than when it used to be managed as a tailq. But in
the context of a red-black tree for dynamic priv lookups the benefits
should still outweigh the slight increase in memory footprint.

Conflicts:
	bin/varnishd/cache/cache_vrt_priv.c

Fixes #3003