Its first action ${string,repeat,<uint>,<string>} helps simplify many
unwieldy test cases that will hopefully be easier to edit from now on.

Instead of having a mere value, these would be able to compute a macro
expansion. We parse the contents inside the ${...} delimiters as a VAV,
but there can't be (yet?) nested curly {braces}, even quoted.

The first argument inside the delimiters is the macro name, and other
VAV arguments are treated as arguments to the macro's function.

For example ${foo,bar,baz} would call the a macro "foo"'s function with
arguments "bar" and "baz". Simple macros don't take arguments and work
as usual.

The latter operates on a VSB, which is always what call sites are doing
anyway. It also takes the responsibility of ignoring unknown macros, in
preparation for more responsibilities that will also require the ability
to fail a test case.

Commas unlike spaces are hard separators, so a trailing comma leads to a
last empty parameter.

A comma may appear after an argument's "trailing" spaces and should not
result in an additional parameter. In <foo  , bar> we should expect two
fields, not three.

Comments are only treated as such at arguments boundaries: <foo #bar>
parses one field <foo> and <foo#bar> parses one field <foo#bar>, taking
the shell word splitting as the model, cementing what was the existing
VAV behavior in the first place.

Unlike the shell, we don't expect quotes to start in the middle of a
token so <foo"bar> is invalid unless escaping was disabled.

Fields that are quoted need a separator: <"foo""bar"> is therefore
invalid unless escaping was disabled.

At least not on my system, where "x%02x" doesn't strictly require 2
hexadecimal digits.

This reverts commit d3df1f64.

I didn't mean to push it, it predates VAV's test driver.

Let's consider the following VAV strings:

    "foo bar baz"
    "foo,bar,baz"
    " foo bar baz "
    " foo,bar,baz "
    "  foo  bar  baz  "

They are all equivalent because consecutive spaces are considered to
form a single separator. However, consecutive commas aren't:

    "foo,bar,baz"
    "foo,,bar,,baz"

In the example above the first string has 3 arguments while the second
has 5 of them. This behavior was however inconsistent with trailing
commas:

    "foo,bar,baz"
    "foo,bar,baz,"
    "foo,bar,baz,,"

When it comes to trailing commas the first two strings above would
contain 3 arguments, and the last string would contain 4 arguments.

With this change, they respectively contain 3, 4 and 5 arguments.

Otherwise we can still overflow in the absence of a null terminator.

There's no longer the guarantee of a null character at the end of a VAV
string.

It started with one corner case, then I found more, then I found new
potential corner cases introduced by my own attempts at squaring them.

I decided to take a step back and start some VAV test coverage. With
something not too complicated to edit, dealing with the corner cases
should increase confidence with the introduction of new cases easy
to review.

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.