Avoid (potential) issues due to the monotonic clock not advancing for ~10
seconds such as for virtual machine snapshots or migrations.

In such a scenario, we would kill a child after cli_timeout anyway, so
using the same timeout by default for the watchdog also should reduce
the additional risk implied by it.

Ref	#2814

I never thought that I'd have to fix a string concatenation problem in
a BusyBox awk program to generate VT100 code in a container, but here we
are:

echo | awk 'END {print "foo" "" ++a, "foo" ++a}'

should output "foo0 foo1", and for all the ?awk I tested, it does,
except for BusyBox awk who thought funny to output "0 foo1", breaking the
teken_state.h file.

Fixes #2820

Conflicts:
	bin/varnishtest/tests/v00041.vtc

These are the most significant changes for 6.0.2, as far as
I can see.

and make sure the expects in the test are scrupulusly correct.

Ref #2792

Conflicts:
	doc/changes.rst

See details in r02275.vtc for why there isn't a test case for this.

Conflicts:
	bin/varnishtest/tests/v00058.vtc

Counts the number of times we failed a response due to running out of
workspace during delivery.

Conflicts:
	bin/varnishtest/tests/v00058.vtc

As long as we are not queuing any threads, there is no queue to
move. We record the queue marker the first time we notice queuing and
only then see if it doesn't move.

Fixes #2794

The previous code was correct already, but we can make it
clearer that HFP implies OC_F_PASS

Also test explicitly that both HFM and HFP have their objects
slimmed.

Closes #2768

When producing files with "foo > file", always use the pattern:

	foo > file.tmp
	mv file.tmp file

Otherwise program failures end up generating partial content and
make will not even rerun the failing program next time you type make.

Actually clean CLEANFILES in the clean target.

The reference dir is not built, but it should be in the distfile

We use double for all time representations, yet monotonic time,
real time and durations are not to be confused.

Also, we might want to change the representation of time in the
future.

To get an implicit documentation of the semantic type of a time
value and to facilitate working on the latter, we start off by
introducing simple typedefs which neither inply any change nor
offer any type checking. But they pave the way...

Closes #2783

The panic string is added as a JSON string in the output array.

* Each param is represented as a JSON object listed in the output
  array.
* The object's "value" field contains the current value, which can
  have different types -- int, float, string or boolean.
* There is no -l form with param.show -j, each object contains the
  full description.
* But "param.show -j the_param" or "param.show -j changed" may be
  used to limit the number of objects in the output.
* Each object may or may not have any of the fields "minimum",
  "maximum", "default" or "units", depending on the param.
* Params not implemented on the present platform just have
  "implemented":false along with the param name, and no other fields.
* The values of the "minimum", "maximum" and "default" fields are
  always strings.

I failed to consider the hypothetical case that there is only gethrtime()
and no clock_gettime(CLOCK_MONOTONIC).

Throw out the conventional wisdom and base the decision on a micro
benchmark.

clock_gettime() is now preferred if it is consistently at least
double as fast as gethrtime(), which is the case on varnishdev-il,
the SmartOS vtest machine.

config.log gives details on the performance check, sample output
below:

configure:22703: ./conftest
hrtime              45989530 check 16748699083977959327
clock_gettime        4119385 check 16748701613138517215
...
hrtime              48113108 check 16748749015170035860
clock_gettime        4020802 check 16748751585081458308
clock_gettime wins 10/10