otherwise the topreq thread cleanup may race us and clean things under
our feet. In this case it should not really have mattered because of the
topreq waiting for the subreq, but anyway, this is how it should be.

We now fini the root pesi while other tasks could still be running

This reverts commit 92621497.

because, as in the case of pretendgz, they may be chaging the next
level up.

e00023 passes now

https://github.com/varnishcache/varnish-cache/issues/3028

fiddling the filters manually really does not make much sense, in
particular not for our test-cases which are supposed to closely match
varnish-cache serial esi behavior

I _suspect_ this caused issues with make failing in dependency tracking
for me, like:

make[2]: Entering directory
'/home/slink/Devel/varnish-git/libvdp-pesi/src'
  CC       vdp_pesi.lo
mv: cannot stat '.deps/vdp_pesi.Tpo': No such file or directory
Makefile:700: recipe for target 'vdp_pesi.lo' failed
make[2]: *** [vdp_pesi.lo] Error 1

but better safe than sorry

it's too early in set_delivered() because set_closed() calls
set_delivered() on a nexus when all children are already devivered, but
that can happen from within the nexus node's fsm.

we will add extra finis when it's safe in a later commit

in the varnish-cache variant of the code this works because not VDP_Push
is used but the internal push to the parent

When subreqs still used the topreq's VDPs, we could not do this, but now
that we properly layer the VDPs again, we can (and should)

waiting for the boc happened at the wrong place

***  v1   debug|Assert error in vped_gzgz_init(), foreign/cache_esi_deliver.c line 163:
***  v1   debug|  Condition(foo->start > 0 && foo->start < foo->olen * 8) not true.