(even if we exec env python, we should check early if we got one)

Instead of trying to steal vbc's away from the waiter, send the
request and wait for the waiter to hand the vbc back to us.

All waiters but poll still disabled ... coming up next.

sparse fd-sets efficiently.

to ensure this order

Don't worry, they'll will come back later.

and the ones which deal with fd's being waited on (Wait_*)

timestamps, when the Bereq timestamp is taken after our write(2)
to the socket, which may have caused us to loose the CPU.

webserver" and dispatches a thread for each incomming connection.

This is an example use:

	server s0 {
		loop 10 {
			rxreq
			txresp -body "foo1"
		}
		rxreq
		txresp -hdr "Connection: close" -body "foo1"
		expect_close
	} -dispatch

Each connection will spawn a dynamically created s%d instance
starting with s1, s2 ...

Each of these will respond to 11 requests on the accepted connection,
the last response will have "Connection: close" and they will
expect the other end (varnish) to do that.

The main limitation on using this for bulk traffic tests is the
finite and limited size of the vtc_log which varnishtest will
collect (half a megabyte).

Test b00048 is about as much traffic as will fit in the vtc_log.

Seen on a solaris vintage edition (snv_111b) as SIGSEGV caused
by strlen(NULL) in r01036.vtc and r01037.vtc: a z_stream msg
can be NULL.

Changes:

* 302 Found
* 307 Temporary Redirect

  Do not apply the default ttl, only set a ttl if Cache-Control or Expires are
present.
  Responses with these status codes are not cacheable by default

* 414 Request-URI Too Large

  Cacheable with "heuristic expiration"

https://www.varnish-cache.org/patchwork/patch/251/

This hopefully makes l00002.vtc less prone to error.

over the weekend:

Just because we have a bo doesn't mean we have a bo->beresp any more,
find the C-L header in the req->resp.

64bit processors.

We have to restart the server instance when we have writes which
might fail.