A failed fetch won't have the storage trimmed, which may result in an
empty storage element in the body list. Do not assert on non-empty
size in the simple iterator.

Fixes: #2186

This can be reintroduced at a later time when someone feels like
fixing / rewritting it.

Related to #2147.

closes #2014

This round of fixes was originally from work-in-progress in #2174 but
the way forward is to remove the autotools. Since #2174 became obsolete
they should be checked in independently.

Those are warnings we should be able to comply to, but are commented
out since they are clang-specific, but I'm not sure how `optreset`
should be handled so I left that one alone.

Closes #2174

Refs #2139

not accidentally produce '--' and '++' operators.

Fixes	#2184

I noticed that some shells like ye olde bash available on SmartOS don't
treat the following construct as single a token:

    ${dir}/${file}

The following expands a single token on the RHS even if the variable
contains spaces:

    var=${dir}

But a token involving a regular string too needs to be protected by
double quotes:

    var="${dir}/${file}"

Even when none of the variables contain blanks.

Refs #2139

IOW if we ended up in vcl_backend_error{} or failed after returning
delivery in vcl_backend_response{} (e.g. we did not receive enough bytes)
we will bump this counter.

it slows things down.

Many of these could benefit from a rethink now that we can expect
a pattern also on shell commands which succeed.

Test varnishd in -F mode with out VCL

be found are options to "shell".  Deprecate err_shell.

Structure output to always be prefixed by "shell" since we're running
at the top level.

Also prefix commands with "exec 2>&1 ;" to join stdout+stderr by default.
This still doesn't cover the shells stderr in case of bad shell syntax,
which is annoying, but not worth fighting for right now.

to start the child process.

Add bad_backend macro and use it instead of ${bad_ip}/port,
should shave a few seconds here and there.
While here also replace some unneeded ${bad_ip} entries.

If you give multiple -f arguments, the resulting VCL's will be
"boot0", "boot1", ... "boot668", "boot"

And the last one will be the active one.

The plan is to also allow both specification of an (optional) label and
which VCL is to be the active one, but I want to think about if we should
shoehorn that into -f or use a different option letter.

all other modes than -d.

Allow -f '' as an override for people who really want this.