Fixes #1765

understand them.

Fixes: #1770

For continuous updates we can always use a shell loop.

Fixes #1760.

Please note that using underscore in HTTP headers is considered a
really bad idea because many application frameworks map minus to
underscore in environment variables.

Fixes: 	#1768

Discussed with Martin.

Add commas to panic line endinges consistently

This dumps some useful bits about the state of the client connection.

If s_indent > 0 and the buffer is empty, it would check s_buf[-1] for
the '\n' character.

Now it will indent either on previous character being a newline, or on
empty buffer. This allows indenting also the very first line of a
buffer.

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