Alpine 3.14 includes a newer version of musl that uses the newer
faccessat2 syscall, which is not yet allowlisted by the seccomp filter
in older Docker versions. Docker 20.10.0+ allows this new syscall.

In this patch, we configure Circle to set up a Docker 20.10+ environment
where we can run Alpine 3.14 builds.

Until we figure out how to work around the build failure since "latest"
bumped to 3.14.

This has confused at least one user troubleshooting this area.

There are more assertions on sockets not use file descriptor 0, but
not being aware of any examples of those being actually hit, I prefer
a minimal fix.

Fixes #3636

Make the type-specific fields stand out without the help of comments.

While in itself this is not a slow test, on a loaded system the
connection failures can degrade the run time dramatically, like 20
times slower.

To save some time here and there, some client sessions were folded
together where it made sense. Also no two clients share the same name
to make it easier to spot the offending one in a test log.

More importantly, the holddown test at the end which concerns the very
first VCL is now put at the beginning where it belongs, and also where
tweaking backend_remote_error_holddown will actually have the desired
effect.

Despite 1s of delay we sometimes observe a zero Age header, which is
consistent with being under the max-age of 2s and should not fail.

There's always the possibility to fail reusing s2's first connection
after it was closed.

On a loaded system the delay may not be enough, a barrier should.

Spotted by flexelint.

Better diff with the --ignore-all-space option.

With a non-deterministic `expect * * ...` the logexpect thread would
never consider itself to be done if the vtc ends if one entry was not
seen in the vsl.

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.