... which would require error handling on all of the call stack upwards,
which is not that trivial an endavour. Also, for the calls via
VSMW_DestroyCluster(), we are actually about to free space, but
temporarily need more.

Other ideas:

- panic, but leave a better error message
- monitor free space and refuse loading vcls if insufficient
- maybe as part of some more general vcl management (e.g.
  "maintain max xx vcls loaded - aka auto-discard)

Ref #2764

We only need to wake up vbp_thread if the probe we insert on the binheap
has become the next due. As a binheap_root() call is cheap and saves
posting many signals, this optimization should be worth some extra
lines.

Also we add a function for the two places where we insert into the heap.

Ref #2976

We could also move the VSL() outside if we copied dir->vcl_name

The due time of the probe which has just finished may be earlier than
the previously earliest due time, so vbp_thread needs to be woken up to
update the nxt value

Fixes #2976

Via lgtm.

This reverts commit e7d5fb68.

Apparently this change looks intentional, but it should be revisited as
it makes troubleshooting significantly harder when logs (for example
Backend_health records) aren't explicit about the backend they are
referring to.

Instead of looking like the backend's VCL name we only get the symbol
name in logs, unlike the CLI. This brings back the full ${vcl}.${symbol}
name everywhere.

the per-release documentation and rearrange things a bit.

Competent review is requested.

This one is much more tricky to use though, certainly not for
automation purposes.

Slightly enhanced compared to when they were first used. I ran them and
found more opportunities to polish the code base.

I also decided to lowercase semantic patch file names, and to not
mislead people about the WS_Reserve change being a vmod-only thing.

Add Project Governance info.

Closes #2971

We handle the error case just above

Ref:
https://github.com/varnishcache/varnish-cache/pull/2969#pullrequestreview-224802203

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

We do not replace the stale oc when
- abandoning the bereq
- leaving vcl_backend_error with return (deliver) and beresp.ttl == 0s
- there is a waitinglist on this object because in this case the default
  ttl would be 1s, so we might be looking at the same case as the
  previous

Thank you @mbgrydeland for the review and spotting a mistake.

Historically, all initializers called from VGC_Load() would handle
failures individually (return (1) from VGC_Load) or not fail at
all. Now that we got VRT_fail(), it makes sense to generalize.

The upcoming use case is to properly handle failures from
VRT_new_backend_clustered().