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

Fixes #2746

Increasing libvarnishapi.so version from 1.0.6 to 2.0.0

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

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

Fixes:	#2745

... argument to specify a custom location

Fixes #2742

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