For tests which do not require new connections for repetitions (for
example because of possible error conditions), this reduces run time
and the number of required ephemeral ports.

The latter is a real issue when running many vtcs in parallel which
each run many repetitions of the same test (for example to check for
possible race conditions). When ephemeral ports are exhausted,
seemingly unrelated issues like the following can be observed:

---- c1010 14.0 Failed to open 127.0.0.1 59763: (null)

**** v1    1.8 vsl|          0 CLI             - Wr 300 65 Listen failed
on socket '127.0.0.1:33328': Address already in use
**** v1    1.8 vsl|          0 CLI             - EOF on CLI connection,
worker stops

An argument could be made that UDS does not suffer from the port
exhaustion issue and thus such tests could be migrated to UDS. Yet
also for this case the run time point remains, plus deliberately
testing many iterations on a single connection could have its own
merits.

Tests 20ab2abc

Conflicts:
	include/vrt.h

This appears to break the VRT interface, but there are symbols we are
willing to break even on a stable branch because they are needed by
VCC-generated code and off limits to inline C and VMODs.

Refs #2800

... and fail the VCL unless successful.

Providing the PRIVs to vmods is a core function, so error handling
should happen outside vmods.

Besides being safe, this initialization can be more efficient than
previous code for PRIVs used frequently within the same subroutine.

An alternative approach would be to initialize all privs once per
task / top request, but unless all privs are actually used in a VCL,
this approach could impose significant overhead, both in terms of time
and memory. By initializing privs once per sub, we impose overhead for
privs which are referenced but not actually used in a subroutine, but
not for all of the vcl.

Fixes #2708

per-task PRIVs.

Fixes: #2749

the purpose of VRT_priv_task()

Previously we used various heuristics (test TCP connection) to avoid
the reschedule if the req was abandonned while on the waiting list.

We also subjected the rescheduling to pool-queue limits like any
new request.

This was all safe because we knew we could clean up the request
state cheaply, even if it was somewhat cumbersome.

Now vmods can have per-task PRIV's and we have no idea what it will
cost us (stack, time, etc) to clean them up, so we cannot burden
J.Random Request who happens to rush the waiting list with the burden.

Fix this by always rescheduling, not subject to pool-queue limits,
and eliminate all the special-casing for exceeded limits, including
the debug feature to force a rescheduling failure and two tests
exercising it.

As a side effect of this, requests on the waiting list gets a
"business class upgrade" over newly arriving requests when there
are no worker threads available.  Given that these requests arrived
earlier, and we already performed work on them, this seems only fair.

Forced to pay proper attention by:      slink

works around #2297

Conflicts:
	lib/libvmod_directors/fall_back.c
	lib/libvmod_directors/hash.c
	lib/libvmod_directors/random.c
	lib/libvmod_directors/round_robin.c

Fixes #2746

Submitted by:	Frederic Lecaille <flecaille@haproxy.com>

Conflicts:
	include/vrt.h

This appears to break the VRT interface, but there are symbols we are
willing to break even on a stable branch because they are needed by
VCC-generated code and off limits to inline C and VMODs.

Refs #2800

Ref: c2888919
     72bacde7
     46f1557d

In other news:  VTEST works.

Fixes: 	#2696

* either NULL or properly named
* only named arguments can be possibly be speficied multiple times
* only named arguments can be optional
* positional arguments could be missing

Fixes #2694

Conflicts:
	lib/libvmod_blob/hex.c

Conflicts:
	bin/varnishd/cache/cache_vrt.c

Fixes:	#2745

Conflicts:
	bin/varnishtest/tests/v00020.vtc

... argument to specify a custom location

Fixes #2742