We shouldn't need to care about all the details when autoreconf(1) can
do that for us. The autoworld has changed over the last decade and this
only affects Varnish developers since we ship release archives with a
turnkey configure script. So let's see how much wreckage this change will
cause.

The script remains until its refcount drops to zero.

In order to get early feedback for MacOS the relevant Travis CI job is
already updated.

When we release a dist archive, it comes with the documentation but
since some of it is generated by programs we end up it makes no real
difference, and actually it makes things worse: rebuilding from the
dist archive ends up with a rebuild of the documentation because some
sources ended up being rebuilt. In other words, the documentation we
ship is dead weight in the dist archive and doesn't reduce the number
of build dependencies downstream.

From now on, rst2man remains mandatory to build our manual pages but
can safely be omitted by packaging scripts.

taken from varnishtop. NOOP because #if 0'd

This is understandably no longer present on the buster base docker
image, but I'm not adding this to installation instructions in the
documentation because I hope to remove that dependency before the
next release.

At this point I'm wondering whether we should talk about hacks when we
really add missing dependencies. In some cases it boils down to RST
being generated by programs we need to compile, what I call "regular"
targets here.

One exception could be the changes builder, but if we ever reach the
point where we can automate the changelog initial creation we can bring
it back.

The previous commit added symlinks for source files.

Fixes #3309

... if they differ.

Ref #3309

Partially reverts commit 883fddfe.

Ref #3309

This was brought up by Dridi in an email response to
b90b60d0:

Initially, I also thought that we should VRT_fail() for an invalid
parameter, but on second thought I realized that, as the shard director
supports request-time reconfiguration, graceful error handling should be
possible, so VRT_fail() is too hard.

I think that even returning false for .add_backend() is too harsh, as an
invalid weight is probably not too much of an issue to abort the
reconfiguration in the case of caller error handling.

That said, this might all be over the top. But I really do not want to
run into the (still unfixed) case I saw recently trying to base64 decode
an invalid input, which is not possible to handle gracefully.

... to be more in line with other bundled directors

from flexelint review

We implement weights by scaling the number of replicas of each backend.
The replicas parameter of .reconfigure() remains a minimum.

For existing vtcs, the Debug hashcircle output has been compared
before/after this change to ensure that behaviour is exactly equivalent.

For for wighted backends, it has been checked that the number of
instances per host on the hashcircle matches the expectation.

Also refactor and clean up some of the code:

- consistently make the number of ring points a uint32_t
- some constification

Ref #3276

The first hashcircle point of a backend was saves as canon_point, but
never used for anything but JSON backend.list output.

I assume no-one needs it. Famous Last Words (tm).

Some operating systems still report core-dumps in process exit-status
even though the core-dump was eliminated with setrlimit(2).

feature bits.  Merge it into "short description" (which can be
longer now), reorder features and improve messages.

VTC's change because the exit-instead-of-abort-hack goes away.

Without syncvsl, client N+1 may emitting VSL before client N
has flushed its VSL.

(In general we should probably always use syncvsl with logexpect)

Refs #3303

VCL failure should abort execution, but vcl_recv would possibly modify
req and even continue execution in vcl_hash.

Refs #3303

Children shouldn't be able to mess with their parents, even though in
practice they do.

Simply make sure we don't allow symbols starting with an underscore
symbol.

Refs 9a14e68e

This change is binary compatible.