Reported by Justin Lloyd.

Refs #3565

See Also: #3557

Also compare in the exact resp.body, because now we can.

This is a TTFB optimization: I noticed that, when streaming, we would
only sometimes send headers while waiting for more body data from the
backend, depending on the amount of body data read ahead when reading
the backend headers.

The flush_head debug bit would avoid the delay, but it leads to an extra
flush in all cases, even when we could send some body data down the line
with the headers.

This trivial patch peeks into the busy object to determine if the
first ObjWaitExtend() is likely to block and, if so, issues a flush,
which will cause the headers to be sent in addition to any initial data
VDPs might have to send.

The assertion that the stale objcore of a conditional fetch cannot be
failed unless it was streaming is incorrect. Between the moment when
we grab the stale objcore in HSH_Lookup and the moment we try to use
it after vcl_backend_response, the backend fetch may have completed or
failed.

Instead, we need to treat an ongoing fetch and a failed fetch as
separate checks since the latter may happen with or without a boc.

Please relace the vtree.h #pragma change of this commit with a better
solution once you have one.

777e03ba had the disadvantage that it
requires all vmods to adjust their build, besides affecting more code
than necessary.

Under the assumption that the issue with VRBT is not acutally a
violation of strict aliasing, but rather only a violation of gcc's
pedantic "compatible lvalue rule", we silence gcc warnings rather than
turning off strict aliasing.

Note that this is more convenient, but also more dangerous, because we
fail to catch any actual strict aliasing errors where vtree.h is used.

This reverts commit 777e03ba.

Move the address strdup() to where the acl_e is allocated.

This plugs an utterly insignificant leak for error returns from
vcc_acl_entry().

Apologies for the slight back and forth, but I now think this is a
better way to make clear to flexelint that we either keep an allocated
acl_e or not.

This partly undoes changes from bf854df6

To review, I recommend diff'ing to a3664ead

Ref aff516b7
    f65f7148

Ref aff516b7
    f65f7148

We only ever insert copies into the tree in vcc_acl_add_entry()

note: struct acl_e could be compacted, but we prefer clarify over
efficiency in VCC.

Reduces conflicts with a held-back PR

As of now, this makes no difference to the vcc-generated code.

Each their own variant, *sigh*

No idea why I just overlooked these

to match the character at position 0x2F '/'

There's no point waiting for the backend to complain if we weren't able
to properly send the backend request.

Fixes #3556