previously, we called it way too early from within vdp_pesi_fini() /
vdp_pesi_bytes() - see 6632dc5d

but the call from vped_deliver() was still from within the FSM, and we
need to finish additional cleanup in ved_task() before we can let the
topreq thread start delivering and possibly fini'ing / freeing our node.

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)