much of the rest of the unpend design and state management assumes that
nexuses got nodes below.

By all means we do not want to start removing nodes from the tree,
because that would introduce even more sync or races with unpending, so
the logical solution is to turn the node into a zero T_DATA node.

ref: 5a03b1ef

we do need to differentiate the cases here, depending on which one, we
need to fini the task before or after some other action.

once the subreq is picked up by delivery, it could no longer be true

sometimes accounting is missing 8 bytes - we would expect:
ReqAcct "^29 0 29 192 104 296$

because, when this happens, the subreq accounting and the response
are correct, I assume this to be an issue in varnish-cache

at esi_level==0, accounting is not our busines, only on higher levels we
need to account when pushing bytes up so ReqAcct contains the bytes
produced by that layer.

we will be using it again, but slightly differently

this was intended to weed out additional errors, but right after the
set_closed & unluck, the topreq thread may deliver our node

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.