Coverity fails to see that with at least 2 OC refs on entry to EXP_Insert,
and one deref if race, then at least one ref remains. Attempt to coerce
acception.

The log readers would not complete the acquire/release pair of memory
fence operations when waiting for new data to appear in the shared memory
log. With this, a VRMB() is issued after having waited for the
VSL_ENDMARKER disappears, and before using any data after it (including
the deciphered length data).

Some mistake in the previous commits has left vtest maschine's tree in
an unclean state with bad symlinks.

Try to avoid such issues in the future.

Either I need to come up with a better idea or leave this with someone
else.

This reverts commit 37215599.
This reverts commit 2754e02e.
This reverts commit d7d31e47.
This reverts commit 803b9a0c.

... trying to understand the reason for failing builds.

Apologies!

in particular, do not copy files which we are about to generate

(side note: If I had not before, now I really detest this...
 all I really want is working VTEST builds, there should be a better
 way)

In the previous commit, I argued that adding the link job to
`BUILT_SOURCES` was the better option than adding it to the `all`
target, but I overlooked the fact that also the `BUILT_SOURCES` are
built in parallel (only before all other targets). Thus, we still need
an explicit dependency on the link job.

The phony target was executed unconditionally and would thus race.

A real target (using `index.rst`) does not race and has the additional
advantage of simplifying the code (avoiding a condition in the shell
code).

It seems (at least GNU) `make` outsmarts the attempt to use a file from
`$(srcdir)` as a marker for the link to have succeeded when
`$(builddir)/index.rst` is used as the target.
Using `$(abs_builddir)` seems to dtrt.

Largely unrelated to this issue: The links are required for targets in
`BUILT_SOURCES`, so previously I added a dependency to the `all` target.
Having the link target in `BUILD_SOURCES` seems to be the better option.

Fixes #3370 (I hope)

Restructured so that:

* 'Upgrading' is limited to work that has to be done to upgrade from
  a current deployment to the new version.

* 'Changes' is a comprehensive, user-level description of changes and
  new features.

Conflicts:
	doc/sphinx/whats-new/index.rst

Contrary to what the documentation stated, PRIV_ arguments aren't
unnamed by nature with the current vmodtool script. Both the generated
struct and JSON descriptor would account for named PRIV_ arguments and
the only limitation was in libvcc.

It was really a bug in the sense that vmodtool would generate C code
incompatible with the code generated by libvcc. It was simpler to fix
libvcc and allow VMOD authors to give meaningful names to PRIVs if they
happen to use them in conjunction with [optional arguments].

Refs 82491c2a

- remove a duplicate sys/wait.h include
- remove a stray vapi/voptget.h include
- move include in vsig.h to the right place

Mainly WCOREDUMP is undefine but WIFCORED has similar semantic.

Use <stdatomic.h> if we have it.

Let Ancient FreeBSD without <stdatomic.h> fall back to the __GNUCC_ inline assy.

This otherwise doesn't work with [optional] arguments.

When varnishd is started as root (or otherwise will a full privilege
set), the user will rightly expect that whatever permissions and mode
bits are set for a socket, varnishd will fix them to the specification
from the -a argument.

Spotted by Coverity

Currently fails with "unsupported", later will turn into BLOB.

Fixes:	#3360

in VRT_priv_task() we asserted that only one of ctx->req and ctx->bo is
set when not in vcl_pipe {}, but we also need to extend that assertion
to when ctx->method == 0 after vcl_pipe as finished because
VRT_priv_task() could be called from director resolution.

Being at it, I also noticed that our behavior in vcl_pipe {} is
inconsistent as, from the shard director perspective, it is a backend
method. So now, vcl_pipe {} is handled like vcl_backend_* {}.

We still need to make up our mind about #3329 / #3330 and depending on
the outcome we might need to touch some places again which were changed
in this commit.

Fixes #3361

The temporary code that accumulated in order to implement generic type
methods is now a bit more tidy.

VMODs can now use the same facility as native types to find methods
based on the type of the instance instead of the instance itself.

Because SYM_METHOD symbols are tied to a type instead of an instance
we lose that "extra" argument. To circumvent this, an expression will
keep track of the instance before evaluating a method.

With this, VCL expression evaluation is no longer aware of methods
implementation details, and feeds entirely from the symbol table.

Although at this point we are still using the per-instance symbols from
the table.

For example with the following:

    new fb1 = directors.fallback();
    new fb2 = directors.fallback();

We will get the following entries in the symbol table:

    object    directors.fallback  41 41 directors.fallback
    method    VOID                40 41 directors.fallback.add_backend
    method    BACKEND             40 41 directors.fallback.backend
    method    VOID                40 41 directors.fallback.remove_backend
    instance  INSTANCE            41 41 fb1
    func      VOID                40 41 fb1.add_backend
    func      BACKEND             40 41 fb1.backend
    func      VOID                40 41 fb1.remove_backend
    instance  INSTANCE            41 41 fb2
    func      VOID                40 41 fb2.add_backend
    func      BACKEND             40 41 fb2.backend
    func      VOID                40 41 fb2.remove_backend

As long as the func symbols exist, and the instance symbols have the
generic type INSTANCE, the expression parser will not try to evaluate
the method symbols.

But the type-based symbols aren't ready to be evaluated yet so we can
have peaceful cohabitation for now. This makes this part of the code
even more complicated but it will eventually straighten up once the
SYM_FUNC symbols are gone.

Now they appear as ${vmod}.${constructor} instead of VOID in the symbol
table. The effective type is based on the VMOD's name, regardless of
whether it was imported with an alias or not.

This enables the possibility for other kinds of SYM_METHOD symbols with
different parsing rules.

Technically the lookup is TYPE.METHOD so it's not as simple as calling
VCC_SymbolGet() with the correct namespace.

The SYM_METHOD kind of symbol was already present but never used so it
just found its purpose.

They appear in their dedicated symbol table:

    /*
     * Symbol Table MAIN
     *
     * reserved  VOID       41 41 acl
     * reserved  VOID       41 41 backend
     * [...]
     */

    /*
     * Symbol Table TYPE
     *
     * none      VOID     40 41 BACKEND
     * method    BACKEND  40 41 BACKEND.resolve
     * none      VOID     40 41 STEVEDORE
     * method    BYTES    40 41 STEVEDORE.free_space
     * method    BOOL     40 41 STEVEDORE.happy
     * method    BYTES    40 41 STEVEDORE.used_space
     * none      VOID     40 41 STRINGS
     * method    STRING   40 41 STRINGS.lower
     * method    STRING   40 41 STRINGS.upper
     */

Unlike VMOD functions or object methods, native type methods are never
invoked as a standalone statement:

    strings.upper();

They are only evaluated atop an expression:

    (string expression).upper();

So any VMOD named after a type, like vmod_blob, should not conflict with
native type methods in the symbol table. Unless a symbol already exists
in the MAIN namespace, like reserved keywords acl and backend.

This introduces two namespaces MAIN and TYPE to allow top-level symbol
collisions for type methods.

For example, `backend` is a reserved keyword but `backend.resolve` is a
type method. It is impossible to declare such a method symbol because it
would require its parent `backend` symbol to be a type symbol.

There would be a conflict between two `backend` symbols of different
kinds. The same would apply if the BLOB type had methods and vmod_blob
was imported.

At this point only the MAIN namespace is used but the split enables the
symbolization of types and type methods down the line.