constraints.

Related to: #2763

Fixes #2761

The only way H2_Send_Frame can fail is if the TCP connection is
dead, so reach out and set the session errored and be done with it,
rather than pass an inconvenient error status down through the callers.

While here use writev(2) instead of two write(2) calls.

Most of the heavy lifting by:	slink

Fixes: #2760, #2754, #2654

require new bytes to be received.

Refs 9804794a

Partial fix for #2654 and #2754

The syntax is

	expect <skip> <vxid> <tag> <regex>

Also remove some bogus .*$ from regexen (waving to @slimhazard)

return(pass) from vcl_recv does not take a duration argument

Fix vmodtool with python3

Without this patch, it did
TypeError: Unicode-objects must be encoded before hashing

Fixes: #2436

I belive this makes our builds reproducible.

Fixes:	#2436

Fixes: #2753

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

... 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