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