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.

Also (re)used to make fork privileges available when we start a
subprocess: As we are going to apply the JAIL_SUBPROC privileges to the
forked process, having slightly eleveated privileges only agross the
fork() should not cause any harm.

	-

This concludes the current series of Solaris jail patches, hopefully.
With this commit, varnishd started with pfexec ("root privileges") keeps
the following privileges only (ppriv -v output) on Solaris:

* master::

  flags = PRIV_AWARE
        E: file_read,file_write,net_access
        I: none
        P: file_read,file_write,net_access,net_privaddr,proc_exec,proc_fork,proc_info,proc_owner,proc_setid
        L: file_read,file_write,net_access,net_privaddr,proc_exec,proc_fork,proc_info,proc_owner,proc_setid

  notes:

  E: file_read is required for basic config files like /etc/netconfig
     net_access is required for CLI communication

     file_write could potentially be removed if any file write
     operations (e.g. writing vcl files) were wrapped with
     JAIL_MASTER_FILE, but I do not consider this a relevant gain for
     now.

     For other master jail states, E will be momentarily expanded.

  I: will be momentarily expanded for system()

  P: Contains the union of all privileges used anywhere in varnish

  L: Could potentially be reduced further, but P already limits

* worker::

  flags = PRIV_AWARE
        E: file_read,file_write,net_access
        I: none
        P: file_read,file_write,net_access,proc_info
        L: file_read,file_write,net_access,proc_info,proc_setid

  proc_setid is only used when the worker starts and then dropped

  proc_info is only used by vmod_unix