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

LLVM C-compiler.

You have no idea how much or how long (20+ years!) I have missed having
an alternative to GCC.

Remember:

  Mono cultures are particularly bad for you, when they are good for you

Kudos to:       The LLVM team.

Patch by:	scoof
Fixes		#961

as per discussions in httpbis WG

different functions.

I have not managed to write a vtc case for this one, but I am pretty
sure this:

Fixes:	#945

a21746d2.

Fixes: #941

of source code.

This is substantially DocWilcos fix, but instead of adding yet another
unique numbering variable, I have collapsed the once we have into
a single one.

Fixes #948

Use it to hold the derived vary string for the request (if any) and
skip busy objects with non-matching Vary during hash lookup.

Idea by:	sky

Not detected by:  FlexeLint 9.00f
Detected by:  FlexeLint 9.00g

to prevent old junk on the workspace from being taken for valid.

cache_hash to cache_center.

do not trusting) that all objects under an objhdr have the same
Vary string.

Build a vary string for the request on the wrk->ws as we do the
comparison and use it as a cache for subsequent comparisons.

This will also be first step of sky's "pre-vary"

white space.

Repack struct object, reducing a couple of field widths along the way.

This shaves 16 bytes of struct object.

We're seeing at least up to 4k in the wild, so increase the limit
somewhat.

See: #939