When making a connection a "real" backend (VBE), we checked the probed
health state and did not take into account the administrative health
state as set with `varnishadm backend.set_health ... {healthy,sick}`.

Our documentation was not particularly explicit on this aspect either,
but the administrative states `sick` and `healthy` made no sense if
`auto` semantics was implied always. Also, the semantics were implicitly
documented for `backend.list`.

Implementation note:

The relevant change is to call `VRT_Healthy()`, which does check the
administrative health, in place of checking `(struct backend *)->sick`
in `vbe_dir_getfd()`.

As a `VRT_CTX` is required by `VRT_Healthy()`, we change the arguments of
`vbe_dir_getfd()` accordingly: The busyobj can now be taken from the ctx,
but the worker argument differs for pipe mode vs. fetch, so we preserve
it as an explicit argument.

A test for overriding a probed backend as healthy has been added to
c00048.vtc, which requires a second probe to hit server s1 and fail.
This is timing sensitive, so I hope that the backend probe interval
of 5 seconds is long enough for all our test environments. If not,
we probably need to make it longer or add another vtc.

Fixes #3299

Since we no longer distribute it...

It's cheap to rebuild, and it might lead to rebuilding it in $(srcdir)
instead of $(builddir) in a VPATH build. If the source tree is write
protected this will obviously fail.

Reported by phk.

VDP_END marks the end of successful processing, it is issued by
VDP_DeliverObj() and may also be sent downstream by processors ending
the stream (for return value != 0)

VDP_END must at most be generated once per processor, so any VDP
sending it downstream must itself not forward it a second time.

* VDP_bytes()

The only relevant change is the assertion that VDP_END must not be
received by any VDP more than once. This comes with minor
restructuring of the handling of the three actions

* VDP_DeliverObj()

Here, VDP_END is pushed down after succesful iteration over the
objects. We could also send the last storage segment with VDP_END, but
this would require a change in all stevedores. Unless there is a good
case for it, I do not see much value in this minor optimization.

* ESI:

In ved_vdp_esi_bytes we now push down VDP_END whenever we are done
with an ESI object at esi_level == 0.

ved_bytes() handles the pushes from higher esi levels downwards, so
it now changes VDP_END into VDP_FLUSH. We need to remove the
additional VDP_FLUSH from ved_deliver because the VDP_END from
VDP_DeliverObj() needs to be the last bit sent.

The gzgz vdp actually does something which would be impossible for an
esi_level == 0 VDP: push bytes from _fini. This could be reworked, but
there is also no need to.

* range VDP

Here we now send the VDP_END with the last segment before the end of
the range is it.

We also take the opportunity and eleminate null VDP_bytes calls before
the range is reached.

* rot13 debug VDP

Here we need to ensure that we pass on VDP_END

quite work the way it should.

Currently on process pX -expect-text varnishtest uses at most
300000 us pauses. This make it offscale when compared on what
varnish vX -expect does by trying 50 times with 100us pause
in a total of 5s.

Chaning term_expect_text() wait 3s before failing avoid tests
to cause false positive under stress (i.e.: r02990) but putting
process pX -expect-text and varnish vX -expect at the same time
scale.
Signed-off-by: Marco Benatto <mbenatto@redhat.com>

Refs 0c38fc1c

Trimming more of the automake_boilerplate.am fat that prevents using
$(vmodtool) --boilerplate out of tree.

Unlike the PFX that added a -o option to $(vmodtoolargs) this change
doesn't affect already checked-in boilerplate files.

Even when they live in different templates.

Even when it was introduced, it was inaccurate.

e39e5e0d continued

Minor uncluttering, no code change other than use of that local
variable.

The fetch_objcore must not change for the duration of a fetch.

it is part of the filter side of things, while the remaining
declarations in cache_varnishd concern the interface between filters and
the rest of the code.

This also parallels the location of VDP_Push()

Test inspired by Carlos Abalde

		if (e - p < l1 + l2)
../../lib/libvarnishapi/vsl_arg.c  133  Info 776: Possible truncation of
    addition

depending on our platform and the timing of events, we might see another
overflow.

Seen with vtest

---- v1   Not true: ws_session_overflow (3) == 2 (2)

we want to make sure that we do not hit timeout_idle as long as we stay
below it, but the margin of just 100ms has triggered a false negative.
Double the margin to 200ms...

see with vtest (c4u lines extracted)

**** c4u  Loop #3
**   c4u  === delay 0.3
***  c4u  delaying 0.3 second(s)
**** dT   2.025
**   c4u  === sendhex 0d0a
**** c4u  sendhex|  0d 0a
---- c4u  Write failed: Socket is not connected

sorry, I overlooked the sixth spot from a total of five different source
files.

Parameters are passed to vcc via specific setter functions, presumably
to avoid binary compability issues between the main program (here:
vanishd) and a library (here: libvcc).

This commit does not change that interface in any way, but generates
both sides from a common table include to avoid having to edit five
spots in four different source files and write trivial setter functions
for a simple mgt_vcc parameter change.

* there is no NULL filter
* the filter name cannot be NULL or empty

See previous commit: Analogous to resp.do_esi, any access to the
beresp.do_* flags which influence beresp.filters is now a VCL error.

Ref #3002

After fixing resp.filters, resp.do_esi loses its meaning.

Note:

Setting resp.filters also fixes whether or not the gunzip and range VDPs
are being pushed.

These do not depend on switches, but on request headers. So we need to
consider the case that a VCL author

	- fixes resp.filters
	- and then adds or removes relevant headers

* req.http.Accept-Encoding for the gunzip vdp

  if removed: gunzip stays in the VDP list, which is always ok

  if added: that is probably wrong anyway and the VCL author can
  be held responsible for their actions as per the warning in the
  resp.filters documentation.

* req.http.Range for the range vdp

  if removed: the range vdp vetoes itself in the _init callback

  if added: no range handling will be present, which is always ok
  (and see above for VCL author responsibilities)

Fixes #3002

The synthetic response has nothing to do with the filters set for
the original body.

See next commit for implicit test

We do not know if we are going to send a body when we construct the
filter list. It is up to the vdps to handle a null response

Ref #3002

So far, we relied upon esi not being added to resp_filters for no esi
object, but as the filters can be set freely from VCL, the esi vdp
itself should veto being pushed if it has not business to do with the
object at hand.

Ref #3002

sorry, I got the first attempt wrong

reported by flexelint