A failing test may take up to the vtc timeout to effectively fail if a
thread is waiting for a barrier to sync. Barriers now check every 100ms
whether the vtc is done to bail out.

The socket barriers were already polling for 1s, so now they poll for
100ms and leave the loop early when needed.

The condvar barriers now loop over a timedwait, but critical sections
were too wide. There were vtc_fatal() calls under barrier locks that
would defeat the timedwait loop.

Thus critical sections were more carefully laid, allowing multiple
barrier commands to run simultaneously. This also means that besides
initialization, socket barriers no longer touch the lock.

Consider the following diff:

    --- bin/varnishtest/tests/v00056.vtc
    +++ bin/varnishtest/tests/v00056.vtc
    @@ -72,7 +72,7 @@ client c2 {
     } -run

     logexpect l2 -v v1 -g raw -q Backend_health {
    -       expect 0 0 Backend_health "default Went healthy"
    +       expect 0 0 Backend_health "default Went wrong"
     } -start

     barrier b3 sync

With this change l2 would fail early, typically in less than 2s, but the
barriers stuck in a condwait would prevent further progress.

Latch the barrier _after_ reading resp.is_streaming.

It is possible to see the session close after the second request after
timeout_linger triggered.

It started failing out of the blue and it's not obvious why.

The probe timeout is irrelevant, especially under load. And to be
certain, we can witness probe updates to ensure we are testing VCL
with a system in the expected state.

Another case of non-deterministic log order.

Errors may be logged out of order.

See previous commit.

Better diff with the --word-diff --word-diff-regex=. options.

I kept a variable called "s" to cut noise from the diff.

Except that we shouldn't start from expr0 since both use cases clearly
need expr4 parsing. Instead of making assumptions based on the type in
expr0, we split the final expression type check in its own function and
use it to confirm that we are matching a regex or an acl.

Fixes #3628

It works like the hash_ignore_busy flag: it is disabled by default
and survives a restart, but as the name implies will skip vary checks
for object candidates.

When a regex match failed with a hard error (anything which is not just
a "no match"), we would log a VCL_Error but otherwise just fail the
match.

Thus, such failures were likely go remain unnoticed, which could have
serious implications in particular with negated matches.

Ref 6c663836

Spotted by: Coverity

Fixes:

In file included from vev.c:36:
 /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/pthread.h:328:6: error: macro expansion producing 'defined' has undefined behavior [-Werror,-Wexpansion-to-defined]
 #if !_PTHREAD_SWIFT_IMPORTER_NULLABILITY_COMPAT
      ^
 /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/pthread.h:197:2: note: expanded from macro '_PTHREAD_SWIFT_IMPORTER_NULLABILITY_COMPAT'
         defined(SWIFT_CLASS_EXTRA) && (!defined(SWIFT_SDK_OVERLAY_PTHREAD_EPOCH) || (SWIFT_SDK_OVERLAY_PTHREAD_EPOCH < 1))

We tweak down the defaults on 32bit platforms, restore them to the 64bit
defaults

that was a stupid mistake

This test had been disabled before to reduce the maintenance burdon, but
I think it really should be possible to find a regex & pattern to
reliably run into PCRE_ERROR_RECURSIONLIMIT / PCRE_ERROR_JIT_STACKLIMIT.
And it seems that the work to find such a regex & pattern had already
been done for us. :)

Looking after the test made me realize that we really should consider
latching VCL failure for "hard" pcre errors.

This commit is to have a diff in the git log, the next commit will
activate the test.

This is from before the introduction of workspace overflow detection.
Since then we would never silently process failing string assembly.

we test chunked + streaming and gzip + streaming in a number of vtcs
since the do_stream default has been changed to true.

And, yes, these vtcs do succeed.

cc cannot -Wformat-y2k

	cc1: warning: -Wformat-y2k ignored without -Wformat [-Wformat-y2k]

cc cannot -Wformat-zero-length

	cc1: warning: -Wformat-zero-length ignored without -Wformat [-Wformat-zero-length]

The two options can't be mixed together and we should ensure that only
the options we decided to support can be passed along, preventing bit
smuggling.

For a full PCRE spectrum, VMODs can directly use a PCRE library through
its API.

Fixes #3624

... to have a solid baseline

The explicit catch on CalledProcessError will be used in a follow up
commit to ensure that python errors do not stay unnoticed.

Ref #3624

... to make our SunOS vtest build happy again

ld: fatal: file /opt/local/lib/libpcre.so: wrong ELF class: ELFCLASS64
ld: fatal: file processing errors. No output written to vjsn_test
collect2: error: ld returned 1 exit status

The issue here was order of the -L -l arguments when a (32bit) version
of a library needs to be found first in an overridden LDPATH.

Ref 12bbe31f
Ref #3559

We might want to do something about it once pcre2 is in place, but it
should be noted that concurrent matches on a vre_t could compete over
the limits we can tweak.

Refs #3559

It's more helpful than printing the invalid regular expression, that's
how the spurious "\T" was spotted.

It is interpreted as "T" by pcre but pcre2 is stricter and treats it as
a syntax error. While there may be a bit flag to ignore unknown escape
sequences, it is probably worth hardening instead.

Refs #3559

To make sure it is always readily available without an extra step, and
that it doesn't rot away missing build flags or triggerring developer
warnings like GCC's -Wtautological-constant-out-of-range-compare.

Otherwise we get it from either libvarnish or libvarnishapi.

Refs #3559