Ironically, this does NOT fix #971 (see if you can handle this, trac).
(WIP)

the silo into VM.  If this fails or we get garbage, the silo will
be cleared.

Fixes	#962

expect:

Clamp rather than overflow on child indexes when we get to the
end of the UINT_MAX items we can support.

Found by adding a lot of asserts and brute force testing, both
of which I have left in.

Fixes       #967

May also be relevant to #827

end of the UINT_MAX items we can support.

Found by adding a lot of asserts and brute force testing, both
of which I have left in.

Fixes 	#967

May also be relevant to #827

also have the 206/range handling.

Instead of building the 304 response from scratch, dumb down the
200 response accordingly.

This implement the policy consideration of #970 led to.

Written by:	Martin

prefer IMS, it is less work and less data to transmit.

Fixes	#972

Thanks to:	Martin

into the RFC policy module where it belongs.

Put esi → do_esi in upgrade checklist, fix markup typo.

Fixes #974

Document the TTL record.

Simplify the move from sp->wrk to sp->obj accordingly.

Add a diagram that explains how ttl, grace & keep related to
each other.

Fix VCL's obj.ttl variable to appear to be relative to "now" rather
than obj->entered. (#956)

Also log SLT_TTL when we change obj.grace and obj.keep

Make SLT_TTL always have the same format:
	XID
	"RFC" or "VCL"
	obj.ttl
	obj.grace
	obj.keep
	obj.entered
	obj.age
In addition "RFC" has:
	obj.date
	obj.expires
	obj.max-age

Fixes	#956

Thanks to:	DocWilco

fields in different ways.

Thanks a lot to Andreas Plesner Jacobsen for writing those up.

DocWilcos proposed fix in #956

XXX: the 64k fd limitation should probably be fixed.

dlopen typically only fails here if the child process does not have
access to the build directory and the user runs varnishtest as root
(meaning the child setuids to nobody).  Report the dlerror and give a
hopefully helpful hint to help diagnose the error.

Fixes: #959

dereferencing and destroying a busy objcore.

Free the busyobj in the case that the worker already has one
(potential race condition from the expiry/ban-lurker threads?)

Reminded by:	Tollef
Related to:	#953

Thanks a lot to David for minimised test case showing the bug.

Fixes: #965

to avoid dropping an object on out of storage conditions.

I belive this...

Fixes	#953

Otherwise please reopen.

Ensure that stats are correct if allocations fail.

Don't rely on the VSC counter for checking the limit.

It seems most RPM-based distros has the -p switch to killproc and
status those days, so only blacklist the ones we know about that does
not have it.

Fixes: #969

Make sure we compensate for sizeof(int) and the stuff we have already
read.

Fixes: #848