... hopefully, finally

The previous code pushing additional data was actually working around
other bugs, which _should_ be fixed with
4f9db605 and
6b5c4e45 as shown by permutations.vtc

This should avoid running into #3109 on 6.x

permutations-error.vtc triggers the bad assertion failure fixed in the
previous commit

The previous commit went in the right direction, but was not correct.

For CHK_ORDER, we must only ever look at type != T_NEXUS and check any
T_NEXUS by the criteria originally passed.

CHK_ORDER could be stricter still, after a subtree is completed, we
could communicate up the stricter CHK_PEND, but I do not want to
complicate things further for an assertion.

we do not unpend T_NEXUS nodes, so the following situation is perfectly
legal:

	T_NEXUS
	ST_CLOSED

T_NEXUS		T_DATA
ST_CLOSED	ST_UNPENDING

the purpose of the assertion is that, if a node below a nexus is
not yet unpended/delivered, the following need to be also, but this is
not true for T_NEXUS.

We used to set empty T_DATA nodes to delivered as soon as we encountered
them during unpending. While it seemed like a good idea to not spend
additional work with nodes which do not contain anything, the tree
integrity assertions as well as set_deliver() implicitly assume that

- a delivered node cannot follow an undelivered node unter a nexus and
- once the last node under a nexus is delivered, all of the nexus is
  delivered

Rather than sacrificing the sensible principle that a tree always is to
be delivered top to bottom, left to right, weakening our assertions and
possibly introducing new bugs when handling the resulting special cases,
we go for the simple, clean option and do away with a special case which
will not contribute much to overall performance anyway.

The log for permutations.vtc is too large for the default.

Avoids starting another process.

Avoids the clutter in /tmp.

we run into the problem solved by
https://github.com/varnishcache/varnish-cache/pull/2942

purely for convenience, we send pass'ed backend requests to ourself (in
order not to have to fiddle with the number of requests on servers), yet
it can happen that all threads are used up and the herder fails to breed
more.

So the solution is to ensure that we do not run into any dependency on
the herder.

this stabilizes permutations.vtc for -j 40 -n 1000

The src argument of vped_include() is owned by the caller
vdp_pesi_bytes(), so we need to make a copy on the subrequest's
workspace.

This is not an issue with varnish-cache ESI because the include is
not handed over to a different thread.

we should not emit ReqUnset / ReqHeader if A-E is already correct

reflects 6dbfff12dca895534b090ef9283e75f85659fcfa in varnish-cache

to fail earlier for a bug exposed by this test which surfaces as garbled
URLs.

Also add a test to demonstrate that the error can happen with serial
ESI, so the problem does not depend on pESI, and is not caused by
the VDP.

The moral of the story: don't set beresp.filters without testgunzip
when the beresp is gzipped, or just let varinshd set the default
VFP stack.

in vped_deliver, we used the wrong gzip state pointer for ESI objects,
which lead to the pretendgzip filter not being pushed.

Also, we should respect the RES_ESI bit to properly handle the case when
esi is deactivated on an esi object. (to be tested)

move a block of initializations statements which should run at all
levels

the continue statement continued the inner loop, in fact the while
(node->state >= ST_UNPENDING) was intended to be continued.

I could neither convince myself that this can not cause an infinite loop
nor could I convince myself that it does.

https://github.com/varnishcache/varnish-cache/pull/2796

Before the bugfix for Varnish #3109
(d235b3c90a631ef39fdf0a8103e44ebfb0ddbacb), the gunzip VDP went into
an infinite loop for such a case.

Ref: eb805e8e

we cannot signal task_fini after posting subreq.done, because then we
race the assertion that all tasks are done when we are done delivering.

But we also cannot do it the other way around because then the
assertion that subreqs are done when all tasks are finished, does not
hold.

So the right option should be to do both under the tree lock.

assert_node is only safe under the bytes_tree lock, yet, for the error
case, we called it while other threads could still be running.

Move it until until after we know that all other tasks are done.

This also implies a second asser_node for the retval == 0 case, which
shouldn't do any harm.

should fix:

Panic at: Thu, 24 Oct 2019 14:21:27 GMT
Assert error in assert_node(), node_assert.h line 103:
  Condition((node->nexus.owner) != 0) not true.
version = varnish-6.2.1 revision
9f8588e4ab785244e06c3446fe09bf9db5dd8753, vrt api = 9.0
ident =
Linux,3.10.0-1062.4.1.el7.x86_64,x86_64,-junix,-smalloc,-smalloc,-hcritbit,epoll
now = 29366.422728 (mono), 1571926828.402512 (real)
Backtrace:
  0x43cf3b: /usr/sbin/varnishd() [0x43cf3b]
  0x4a01c2: /usr/sbin/varnishd(VAS_Fail+0x42) [0x4a01c2]
  0x7f6bf06a033c:
./vmod_cache/_vmod_pesi.4d9e0603bac2a2e2b2627f7fe90ff1d55d4759545517c869a5571f16636e230e(+0xe33c)
[0x7f6bf06a033c]
  0x4222b6: /usr/sbin/varnishd(VDP_close+0x66) [0x4222b6]
...

(gdb) bt
 #0  0x00007f6db97d2337 in __GI_raise (sig=sig@entry=6) at
 ../nptl/sysdeps/unix/sysv/linux/raise.c:55
 #1  0x00007f6db97d3a28 in __GI_abort () at abort.c:90
 #2  0x000000000043d232 in pan_ic ()
 #3  0x00000000004a01c2 in VAS_Fail ()
 #4  0x00007f6bf06a033c in assert_node (check=CHK_ANY, node=<optimized out>) at node_assert.h:103
 #5  vdp_pesi_fini (req=0x7f6ba8f52020, priv=0x7f6ba8f57aa8) at vdp_pesi.c:782
 #6  0x00000000004222b6 in VDP_close ()
 #7  0x0000000000464c5e in V1D_Deliver ()
 #8  0x0000000000441eab in CNT_Request ()
 #9  0x00000000004665b3 in http1_req ()
 #10 0x000000000045c833 in WRK_Thread ()
 #11 0x000000000045ccf0 in pool_thread ()
 #12 0x00007f6db9b71e65 in start_thread (arg=0x7f6cdc5dc700) at
 pthread_create.c:307
 #13 0x00007f6db989a88d in clone () at
 ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
 (gdb) f 4
 #4  0x00007f6bf06a033c in assert_node (check=CHK_ANY, node=<optimized out>) at node_assert.h:103
 103                     AN(node->nexus.owner);