The buf_len field is only ever modified by the poll thread and should not
need to be guarded here. This will hopefully silence a coverity warning:

   CID 1485138:  Concurrent data access violations  (ATOMICITY)
   Using an unreliable value of "l" inside the second locked
   section. If the data that "l" depends on was changed by
   another thread, this use might be incorrect.

It might on the other hand complain even harder, I have an alternative
if that happens.

Unlike other threads we cancel in varnishtest there's 2 per tunnel and
they need coordination between each other. The spec thread remains as-is
and the poll thread now checks vtc_stop after each condwait.

With this I'm no longer able to reproduce a21's timeout.

Reverts d4cf677a

The assertion above wasn't enough apparently.

And make a note that we should avoid pthread_cancel(3) in the future.

A wrong WRONG doesn't make it right for SunCC.

To cut down synchronization needs for the very beginning of a session.

The tunnel acts like a client and a server and forwards bytes between
two parties. It can then pause in the middle of a session and control
how much data can go in either direction. Combined with barriers it can
be used to trigger socket timeouts, possibly in the middle of protocol
frames.

A tunnel works with two threads: one to execute its spec and one to poll
both parties and transfer data accordingly. The two threads synchronize
via basic pthread primitives and follow a very simplistic state machine:

    ACCEPT -> RUNNING <-> PAUSED -> SPEC DONE -> POLL DONE -> STOPPED

Despite being simplistic, the coordination of two threads would likely
complicate the implementation of a `-repeat` action, but it is still
possible to `start` a tunnel again as shown in the c106 test case that
exercises basic coverage involving a varnish instance.

Usage is documented in the vtc(7) manual.

Small typo

Ever since my system upgraded haproxy to 2.3.10 this test has
consistently timed out. While that would be a breaking change
involving the independent vtest project too, I think the VTC
syslog spec would work better with something like:

    expect skip facility.level regex

Where skip could be uint, * or ? similar to how logexpect works,
and both facility and level could also be * to be non-specific.
For now, let's hope this does not break the test suite for anyone
else.

under pressure, tests get slow and time out

Considerable work went into RFC8941 to establish that there is
neither a nead nor a reason to support parsing scientific notation
in HTTP header context.