We'll need to change a couple of signatures in the call paths getting here
to propagate up the failure.

Pointed out by nirn on irc.

Original test case by fgsch

Fixes: #1858

This fix avoids a WS_Alloc panic when pushing fetch processors
and should thus avoid panics by overflowing the backend workspace in vcl.

This overflow is logged as FetchError "Bo workspace overflowed".

Other panic points due to workspace_backend being set too low still exist.

Sizing estimate for workspace_backend:

	sizeof(struct busyobj)
	+ 3 * HTTP_estimate(cache_param->http_max_hdr)
	+ cache_param->vsl_buffer
	+ cache_param->http_resp_size
	+ fetch processor memory
	+ space required in VCL

Fixes #1739

Allow to split https URI in the request line

Some submitted by: github::sublimino

None of it was important or troubling.

MERGE NOTE: Changes for gcc 4.9 in the spirit of 2039d8 added.

WS_Assert allows the workspace to be full in its check that `ws->f <= ws->e`.
WS_Reset does not honor this; if a snapshot was taken of a full workspace, and
that snapshot is reverted with WS_Reset, we panic.

This issue was identified by Jozef Hatala <jozef@fastly.com>

Just warn unless --strict is used.  This allows to use the same .vcc in
4.0 and 4.1.

When building multiple vmods from the same source directory,
vmodtool would trample on other concurrent jobs' vcc_if.[ch].

Discussed with phk@.  Fix confirmed by geoff@.

Fixes #1844.

Pointed out by phk@.

I've verified the rest and only these 2 were affected.

tour through vcl_recv{}

on osx.

Use the cli_timeout to control how long the MGR waits before killing
the worker process, and give this test 60 seconds.

shutdown.

When we fork the worker process, we close all filedescriptors we
have not explictly marked for it to inherit, for security reasons.

Operating system libraries may have open filedescriptors (see
end*ent(3)) and there is no way to chase these down.

At least on OSX something related to DNS lookups leaves such
a FD around, and when that code later discovers the FD doesn't
work, it closes it, even though it no longer owns it.

In ticket 1841, that happens to be FD7 which is one of our kqueue FDs.

Normally such library code should set 'close-on-exec' status with
fcntl(2) but that doesn't seem to be the case here, and this bit
of wisdom seems neglegted about 50/50, so it probably wouldn't
help us to examine this.

The fix here is to close the FDs, and replace them with a FD open
to /dev/null, so that there is no risk of information leak, but we
don't reuse the FD for something else until the library has properly
closed it.

Fixes #1841