Previous fix for #2285 (and the duplicate #2624) was missdiagnosed. The
problem stems from a wrong assumption that the number of bytes already
pipelined will be less than maxbytes, with maxbytes beeing the maximum
number of bytes the HTC_RxStuff may need to get a full work unit. That
assumption may fail during the H/1 to H/2 upgrade path where maxbytes
change with the context, or during runtime changing of parameters.

This patch makes HTC_RxStuff not assert if the pipelined data turned out
to exceed maxbytes, but return overflow if we run out of workspace.

(#2624 has received a workaround in the H/2 code that perhaps should be
reverted).

Remove old and now invalid assert.

Change order of evaluation in if-statement to make sure we don't step
outside rxbuf_e.

Previously, tracing the root cause of probe failures was unnecessarily
complicated by the fact that the probe window bits and timing
information were the only source of information when no HTTP status
line was logged and for the case of all the bits being zero, almost
impossible (e.g. differentiating between a local and remote connection
open failure).

We now re-use the response field for failing probes also.

This is similar to the vca pace: Depending on the backend connection
error, it does not make sense to re-try in rapid succession, instead
not attempting the failed connection again for some time will save
resources both locally and remotely, where applicable, and should
thus help improve the overall situation.

Fixes #2622

Previously, we had zero stats on the cause of backend connection
errors, which made it close to impossible to diagnose such issues in
retrospect (only via log mining).

We now pass an optional backend vsc to vcp and record errors per
backend.

Open errors are really per vcp entry (ip + port or udc path), which
can be shared amongst backends (and even vcls), but we maintain the
counters per backend (and, consequently, per vcl) for simplicity.  It
should be noted though that errors for shared endpoints affect all
backends using them.

Ref #2622

... and introduce request functions for this purpose (for busy
objects, there is only one use case yet, so we don't).

Before we reset the workspace, we must ensure that there are no active
references to objects on it. As PRIV_TASK and PRIV_TOP have the same
lifetime as the respective workspace, they need to be destroyed. vmods
must not use workspaces for storing information referenced via any of
the other PRIVs unless the rollback case is considered.

Note that while this bug was exposed by
beeaa19c, it existed all along for any
vmod priv state stored on the workspace, so if a vmod happened to
access a TASK_PRIV stored on the workspace, it would likely have
triggered a magic check assertion as well.

I got plans for making std.rollback() more useful. While this change
is required to do so, it only partly covers the planned changes.

Fixes #2706

in our loops.

is not thread-safe.

Switch from random(3) to testable VRND for same reason.

Fixes	#2684

Reported by:	ernestojpg@github

Fixes: #2700

For the purpose of our signal handler (and, in particular, the stack
overflow detection heuristic) they are identical.

Fixes #2695 (as confirmed by @lkarsten)

Ref: #2693

This is the case for the ctx created for director operations as first
introduced with 5536f102

Alternatively, we could always set ctx->handling to some location
with the same scope as the ctx, but as we are not inside VCL (and
just happen to use the same context for simplicity and reusability
of VRT/vmod functions), adding specific handling appears to be the
cleaner solution.

Fixes #2692