In order to build aarch64 packages it relies on the machine executors
feature based on QEMU. Since the same scripts were needed to build
packages for different architectures they were extracted in standalone
shell scripts.

Alpine Linux packages are now built in addition to RPM and Deb packages
but considering how long emulation takes for aarch64 packages, packaging
was moved to a nightly workflow.

Some changes happened in the pkg-varnish-cache repository to accomodate
the CircleCI reorganization, mainly around dependency management.

More information in the CircleCI README file.

Closes #3313
Reviewed-by: Guillaume Quintard <guillaume@varnish-software.com>
Signed-off-by: Dridi Boukelmoune <dridi.boukelmoune@gmail.com>

Ref #3311

See comments in #3311, but done slightly differently

This is an alternative implementation of #2680

Ref #3312

Closes #3312 (probably)

Fixes: #3266

vcc_compile.h is not generated
EXTRA_DIST is not necessarily generated

- missing dependencies in each of the both places of invocation
- vrt_obj.h is generated, so it cannot be a dependency at the same time

notice with out-of-tree parallel build

Copy paste the text from beresp.status to resp.status about the special
handling of status codes.

Some status codes are illegal and will cause VRT_fail() when executed as
normal set instructions in VCL. But this test is bypassed when status is
set as a side effect of a `return (synth(code))` statement.

This patch applies the same rules as when executing a set-instruction to
the return(synth()) handling.

Fixes second part of: #3301

The compound statement doing return() in VCL may have failed for some
reason, for example running out of workspace while putting together the
reason field. The fail handling would be overwritten by the forced
handling at the end of the generated code for a return statement.

This patch adds a test for the failure condition before forcing the
handling to the result of the return statement.

In VCL we allow status codes larger then 999, and do modulo 1000 when
sending it to the client. But the code to apply the modulo was missing in
H/2.

This issue was uncovered and reported by @Francois-v3.

Fixes first case of: #3301

It's not a gadget for production use.

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.