This reverts commit df9f3489.

It succeeded in terms of determinism but there is another underlying bug
to fix so it will be submitted again via #3178 instead.

The fetch may be interrupted before s1 has time to buffer the complete
response.

This test has been relying on SLT_Debug records from day one and now
that we have SLT_Notice we could perpetuate this information and at
the same time grant ourselves the freedom to explain each case and
which parameters may be used to try to improve the situation.

I'm no longer able to time it out under load.

There was a race with the reuse of s1 and server -dispatch was the
simplest way to also circumvent the race where varnish could retry
before s1 would reach the next accept action.

While at it, add coverage for the 503 case.

Apparently this is missing in sunos+gcc 4.7.
While here tight things up a bit.

The previous tweak paid off, the problem is not an unexpected ReqAcct
when this test fails, but a lack of logs during the check.

The test cases disabling the accept_filter parameter are those involving
GET requests with a body that are meant to be cached, and one test case
covering OOB data. The rest uses the POST method since the httpready
filter will only let syntactically correct GET or HEAD methods pass to
the application.

Apparently FreeBSD's httpready filter considers that a GET request with
a body is syntactically incorrect although this is not specifically said
in the manual. The HTTP specification doesn't forbid such requests and
they are hard to justify considering the semantics of GET and HEAD, but
there are products in the wild relying on that.

On the other hand GET\r\n\r\n isn't considered malformed, see r01881.vtc.

We don't need the dataready filter on FreeBSD for listen addresses that
expect a PROXY protocol header, the httpready filter will effectively
work like that if the request doesn't look like a GET or a HEAD.

Trying to understand why I was seeing setsockopt fail on FreeBSD VTEST
boxes and why it failed with an undocumented ENOENT I finally realized
that I needed to kldload accf_http beforehand.

The ENOENT errno was probably a result of accept_filter code not finding
a kernel module for "httpready".

I couldn't reproduce the failure reported by VTEST but hopefully this
will shed some light next time it happens.

Better diff with the --word-diff option.

The change in u00011.vtc is the result of having two commands starting
with "pi", breaking auto-completion. Fortunately "pin\t" still does the
trick.

It was a bit racy in the sense that the logs for c2 could be committed
before the c1 logs. I hardened the expectations a bit in the process.

This adds the errno value to error logs for TCP fast open and accept
filters. For FreeBSD errno is cleared prior to calling setsockopt with
the hope that it will help understand if it's actually failing with an
undocumented ENOENT.

Speaking of documentation, the return value is either 0 or -1 for so
there's no point in logging that.

Once all instances of a given test are started all of the remaining
tests would free the test data structure, we needed another counter
to keep track of ongoing tests so that only the last one to finish
would do the single free.

This is only a matter of leaving the acceptor loop to always free the
poolsock before returning from the function. This was initially done in
only one place out of three, with no room to exit the accept inner loop
in the absence of an incoming connection.

With this we may have everything in place to drop the drop_pools debug
flag.

Refs 656982a5
Closes #3177

For those that aren't leaked on purpose, that is...

Upon failure, don't destroy the underlying director implementation. When
the deletion code was split in c671bb66
in order to be reused in 61529854, it
mistakenly included the director implementation.

Instead, it's really the caller's job to tear down the backend if it
couldn't be added. Since vbe_destroy operates on a director, it is split
in two to avoid reintroducing the previous "undo" code duplication.

Refs #3176

Otherwise at this point nothing is undone. And backend creation while a
VCL is stuck in the COOLING state should be unlikely enough that we can
assume the happy path by default.

Refs #3176

Fixed in 7ff636dc.

When a VCL is in the COOLING state it is supposed to delete the director
that was being added, but at the same time when a VBE backend fails to
be added as a director it would also undo itself.

This is in general a code path very hard to reach because either this
happens in a worker and the opportunistic check always kicks in to hide
the problem or this is done asynchronously (e.g. non-blocking lookups to
create dynamic backends) and the race window is very small. In order to
solve this the opportunistic check is skipped in VTC mode.

The test coverage with vmod_debug is done synchronously to make things
easier, but for this reason vbe_destroy can no longer expect to only run
in the CLI thread.

This is inspired by a similar patch by Martin for a different branch,
since VRT_AddDirector deletes the backend upon failure, everything needs
to be set up beforehand.

We have to tolerate backend creation attempts in a COOLING VCL because
in the asynchronous case the VCL temperature will change before COLD
events are dispatched so there's no way to prevent a race.

Closes #3176

Refs #3176

if version is trunk, change it to the current date and add a flag file
so that packages can be suffixed with -weekly/.weekly depending on the
platform

VRT_delete_backend() sets be->cooled to non-zero as the only place where
that is done. Assert that it is zero on entry as a check that
VRT_delete_backend isn't called multiple times.

Several functions (VBE_Poll and vbe_destroy) tests be->cooled == 0 to
determine which of the two lists backends and cool_backends a specific
instance currently lives on. If the flag is in the process of being
changed, then the wrong list head may be used and will result in strange
bugs.

We don't need randomness where we could have determinism.

Except in r02275.vtc until the code it refers to stops referring to
subroutines as methods. While I was searching for relevant tests cases
I also broke some long lines.

Refs 17457b48

Refs 17457b48