Based largely on patch from:	Martin

I wonder if we should make the panic output (readable) JSON format ?

Submitted by:	fgs

"2eq" instead of "Req" didn't look right.

Add missing ones, make the order consistent and remove deprecated
options. More to come.

This does say something about how much is used though.

Treat C-L or A-E in 204 backend responses as fetch_error.

This hopefully fixes #1761

We always do the DNS resolution when we hit -a arguments, but the
test that we can bind to the address is postponed until after the -C
argument processing.

Fixes:	#1767

Add extra variables of the right enum types in an attempt to quell a
coverity report about enum type missmatch when reusing the same
integer counter.

Further investigating into root cause scenarios resulted in the
following insights:

* the bad vxid must have got into vtx->key.vxid by way of
  `vtx_parse_link`

* which is only called for `SLT_Begin` (`vtx_scan_begin()`) and
  `SLT_Link` (`vtx_scan_link()`)

(actually this was known before, but I am now confident that these are
the only cases)

There is no case in the code as of 4.0.3 release where `SLT_Begin` is
emitted with an unmasked vxid, so the issue must be root casue in an
`SLT_Link` link record.

In both cases where unmasked vxids are emitted for `SLT_Link`, the id
comes directly from `VXID_Get()`:

* `cache_fetch.c`

  wid = VXID_Get(&wrk->vxid_pool);
  VSLb(bo->vsl, SLT_Link, "bereq %u retry", wid);

* `cache_req_fsm.c`

  wid = VXID_Get(&wrk->vxid_pool);
  // XXX: ReqEnd + ReqAcct ?
  VSLb_ts_req(req, "Restart", W_TIM_real(wrk));
  VSLb(req->vsl, SLT_Link, "req %u restart", wid);

So unless I have overseen anything significant, the root cause must
have been a vxid spill, which was fixed with
0dd8c0b8 (master) /
171f3ac5 (4.0)

`VXID()` masking would have avoided the issue to surface.

This insight is consistent with two observations:

* the issue only surfaced after `varnishd` running for longer periods
  of time

* the issue didn't go away after a restart of the vsl client, a
  `varnishd` restart was required

This gives confidence that the issue has really been understood
completely and that the root cause has been fixed.

This is an additional safeguard against regressions of #1762

WHOA - sorry

We spilled into the client marker bit when reaching 1<<30

modifications relating to the object refcount issue.

is no sane way to refcount (dynamic) backends in relation to VCL
use at this point in the 4.1 release cycle.

Solve the problem, for now, by cooling dynamic backends off for a
minute before actually removing them.

Varnish 5 will have to look at proper refcounting of (all) VCL objects.

we need.

Send warm dynamic backends "COLD" event before deleting them.

with EINTR.

I suspect the underlying issue is that SIGCHLD is being sent
to a random thread and that happens to be the s1 thread on some
platforms.

Partially from minusf via github