Since its primary usage will be workspace logs, workers can be
initialized earlier to offer even more opportunity for logging.

today: VRBT_REMOVE returns the element argument no matter if it was
present in the tree or not, so it can not sensibly be used for assertions.

The old VRT_AddV[DF]P() and VRT_RemoveV[DF]P() are "soft deprecated"
and work the same as previous.  (Hard deprecation after next major.)

Replaced by:
    const char *VRT_AddFilter(VRT_CTX, const struct vfp *, const struct vdp *
    void VRT_RemoveFilter(VRT_CTX, const struct vfp *, const struct vdp *);

VRT_CTX is mandatory.

Both kinds of filters can be handled in one go, but the names must be identical.

VRT_AddFilter returns NULL on success, and VRT_fail'ed error message otherwise.

Supersedes #3287

HSH_Purge() suffers from a problem when there are more objcores on a given
objhead than we can hold temporary references for on the available
workspace, and multiple purges for the same objhead are issued at the same
time.

The previous algorithm would use a flag on the objcores (OC_F_PURGED) in
order to keep track of how far in the list we had gotten. This becomes a
problem when multiple threads are purging the same objhead at the same
time. When a new purge is started, the flags would be reset, which would
cause any existing purge thread to restart. If a steady stream of purges
for a given objhead is issued and enough objcores are present, none would
finish.

This rework uses OC references in the list as bookmarks, in order to know
how far into the list we were when releasing the mutex partway through and
want to resume again. This relies on the list not being reordered while we
are not holding the mutex. The only place where that happens is in
HSH_Unbusy(), where an OC_F_BUSY OC is moved first in the list. This does
not cause problems because we skip OC_F_BUSY OCs.

The OC_F_PURGED flag is removed as it is no longer needed.

The existing r02372.vtc test case exercises this code.

Just like the file cursor reads from stdin when opening "-". And in
addition, teach varnishlog to also write to stdout when it is opening
the file directly. Likewise, put varnishncsa on par with varnishlog in
that regard.

It is now possible to compress binary VSL on the fly without taking
a detour to the file system, see u00019.vtc for an example.

Considering how VUT daemonizes, a "-w -" option in daemon mode becomes
an error as well.

Refs #3740

When vsl_reclen (maximum length of a record) is close to vsl_buffer,
the vsl buffer is flushed to the main shared memory log for every
record. This is because we test if there is space for vsl_reclen, not
the actual size of the formatted log record (which likely is much
smaller).

Fix this by doing the formatting in up to two stages. If the first
stage shows that we overflowed, but would not have overflown
vcl_reclen if there was more room in the buffer, then flush and redo
the formatting. This limits the extra work of formatting twice only to
the one record that happened to overflow the buffer.

Otherwise valid code can panic on workspace exhaustion:

    std.ip(req.http.X-Real-IP, std.ip(req.http.X-Client-IP, client.ip))

If the nested std.ip() call runs out of workspace, it will return a null
ip instead of the fallback, and since the outer std.ip() call is getting
a fallback argument, it will panic upon checking the suckaddr sanity.

Refs a3b26d0b

{req,bereq}.time remain constant across restarts/retries
req_top.time remains constant across esi includes

The other values represent the time when the respective object
was created.

(Last part of #3599)

(4th part of #3599)

(3rd part of #3599)

(2nd part of #3599)

(First part of #3599)

Dont limit ourselves to a set number of VSL records to include
the "0 CLI" we want, various platforms emit a number of Debug
messages relating to sockopt

Use the `process p%d -expect-text` mechanism to wait only as
long as necessary for the "0 CLI"

Dont limit ourselves to a set number of VSL records to include
the "0 CLI" we want, various platforms emit a number of Debug
messages relating to sockopt

Use the `process p%d -expect-text` mechanism to wait only as
long as necessary for the "0 CLI"

Refs #3740