VIP1: PRIV_* visibility and lifetime control

Synopsis

Vmods can create objects using the "PRIV_" mechanism in .vcc files, but lifetime and visibility of these objects are muddled and somewhat mixed up. This VIP proposes to make lifetime and visibility of PRIV_ objects explicitly specified properties.

Why?

Presently it is not possible to create a PRIV_ which is instantiated per VMOD object.

... add more details ...

Alternative Idea: Leave it up to vmods

core code does not necessarily need a notion of which visibility private data of some lifetime should have within a vmod. We could add utility functions implementing an id-based lookup by example of cache_vrt_priv.c. vmods could then use these to add another layer of indirection.

VCL_STRING
vmod_obj_priv_example(VRT_CTX, struct vmod_something_obj *o, struct vmod_priv *priv)
{
   struct vmod_priv *priv_obj, *priv_all;

   VRT_priv_scope(priv_obj, priv, o);
   VRT_priv_scope(priv_all, priv, 0);
   priv = NULL;

   AN(priv_obj);

   // priv_obj is now per-object
   // priv_all has the same visibility as priv had before
}

Alternative Idea: Just keep using VRT_priv_task(ctx, object) / VRT_priv_top(ctx, object)

Since this VIP yielded in no better alternative, at least some vmod authors have used VRT_priv_task() with the object pointer as the id parameter to programmatically get PRIV_TASK scope per object.

See for example shard_param_task() https://github.com/varnishcache/varnish-cache/blob/master/lib/libvmod_directors/vmod_shard.c#L818

The same technique works for PRIV_TOP using VRT_priv_top()

So what is missing is per-object PRIV_VCL and PRIV_CALL, but an argument can be made that these are not required: Objects are per-object-PRIV_VCL already, and PRIV_CALL does not really seem to make much sense with objects.