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

The reason we expect here can be summarized as: this was a pipe
transaction or an error occurred. This could be much simpler if
we replaced enum sess_close with a struct stream_close instead.

Refs dc5bddbd

Please replace this commit with a better solution, if you have one.

e1ac5933 brought us the VRBT node
color encoded in the lower two bits of pointers.

gcc strict aliasing rules (as enabled with -O2 and higher) forbid
aliased lvalue access as in the following macro expanded code:

(*(uintptr_t *)&(parent)->entry.rbe_parent) &= ~((uintptr_t)3);

Until we have a better solution, disable strict aliasing with gcc
for targets with any source file using vtree.h.

Note that we would want to limit -fno-strict-aliasing to individual
compliation units, but automake does not offer a simple and clean way
to achieve this:

https://www.gnu.org/software/automake/manual/html_node/Per_002dObject-Flags.html