See #2967 for discussion

... where we would need error handling

to identify the vmod by its address in other places like vcc-assigned
VRT_priv_* ids

This was actually done with a Coccinelle patch after finding plain
free() calls out of tree:

    $ cat >free_obj.cocci <<EOF
    @@
    expression obj, objp, magic;
    @@

    (
    TAKE_OBJ_NOTNULL(obj, objp, magic);
    |
    CAST_OBJ_NOTNULL(obj, objp, magic);
    |
    CHECK_OBJ_NOTNULL(obj, magic);
    |
    CHECK_OBJ_ORNULL(obj, magic);
    |
    CHECK_OBJ(obj, magic);
    )
    ...
    - free(obj);
    + FREE_OBJ(obj);
    $ spatch --dir . --in-place --sp-file free_obj.cocci

Asking again, could we consider keeping Coccinelle patches around?

Submitted by:	@tnn2

Fixes #2954

Fixes #2953

on ppc64 fedora, the thread_pool_stack minimum is 128kb due to
sysconf(_SC_THREAD_STACK_MIN) = 131072

It does not harm the test to use a larger stacksize, so we adjust it to
this requirement for consistency and simplicity

It is now safe to assume that a constructor is always called with proper
values or never called to begin with, and as such to panic if it's not
the case.

Bonus polish in the files I visited.

Refs #2297

not even in vmod_debug because it sets the only catflap example for the
time being.

Happy new year!

This reverts commit de3e581e.

tests/saintmode/test04.vtc from varnish-modules revealed that there may
be use cases where it is implied that vcl_backend_error will leave a
ttl=0 object and the sale object will remain in place.

This can be resolved by:

	- return(abandon) for these cases or
	- making the HSH_Kill conditional on bo->fetch_objcore->ttl > 0

but I already has concerns regarding the impact of this change and have
them even more now.

We need time to ponder about the consequences and a documented
inefficiency is better than unexpected behaviour in a release.

Our stack space canary in v00004.vtc fell off the twig on fedora rawhide
i686

Thank you to @ingvarha for testing, reporting and all your support
overall!

Fixes #2946 in the sense that we want to treat backend synth like any
other object and kill the stale object it replaces.

The two HSH_Kill calls could also be subsumed in vbf_fetch_thread(),
but after an irc discussion, phk decided that he wanted to aim for even
more consolidation later.

The test checks that we remove the stale_oc, but not when abandoning the
bereq.