For 127.0.0.1, use "None", "${localhost}" or "${bind_addr}" as appropriate.

Instead of ${Xaddr}:${Xport}, use ${Xsock}

For some tests, we need to add a Host header to make them stable for
differing server addresses.

Ref #3490

to support IPv6 only hosts, we try to resolve "localhost" if resolving
"127.0.0.1" fails.

Whatever address we determine is stored in the ${localhost}
macro. Because of the different address:port vs. [address]:port
formats for IPv4 vs. IPv6, we store "${localhost}:0" /
"[${localhost}]:0" in the ${listen_addr} macro.

Likewise we unify the *_sock macros to ${Xaddr}:${Xport} (the colon
used to be missing) for IPv4 and [${Xaddr}]:${Xport} for IPv6.

We also save ${listen_addr} in default_listen_addr for use from within
the vtest code whenever we want to bind to or listen on an emphemeral
port.

Ref #3490

32 bytes are not enough to hold the colons of a full length IPv6
address.

- write to stderr
- output errno for EAI_SYSTEM

for "backend default none;"

Ref #3067

	Connection failed (fec0:: 19925): (null)

The's not an IPv6 address.

*This* is an IPv6 address:

	fec0::205

Before c1352b0b, the function asserted
that getsockname() succeed. We now restore this behaviour in a way which
Flexelint understands (we are returning the memory which we allocated).

When we reserve a session attribute, we now check that the reserved
space is of the expected size.

avoids an second getsockname() in vbp_write_proxy_v1()
avoids a memcpy() in VTCP_my_suckaddr()

In order to run the test we want to NOT be using gcov, so we should test
that the environment variable is empty. In theory that should mean that
GCOV runs should currently fail since the feature check is currently
backwards so I may revert this change if that suddenly happens.

I find `test -z ...` more readable than `[ -z ... ]` in this context, so
if it comes to a revert, I will keep the test(1) syntax.

Flexelint on Linux exhibits exactly the problem described by phk in
his rant at the top of vsa.c, quote:

	Do I need to tell you that static code analysis tools have a
	really hard time coping with (struct suckaddr_storage), and
	that they give a lot of false negatives which confuse people ?

One instance of this issue:

--- Module:   cache/cache_acceptor.c (C)
                                               _
 #... _assert(!!((getsockname(sp->fd, (void*)&ss, &sl)) == 0)) /*lint -restore *
 #... getsockname(sp->fd, (void*)&ss, &sl)) == 0); } while (0)
	AZ(getsockname(sp->fd, (void*)&ss, &sl));
cache/cache_acceptor.c  330  Error 64: Type mismatch (arg. no. 2) (union
    __SOCKADDR_ARG = void *)
                                 _
 #... SA_Build(sa, &ss, sl)) != 0); } while (0)
	AN(VSA_Build(sa, &ss, sl));
cache/cache_acceptor.c  332  Warning 603: Symbol 'ss' (line 318) not
    initialized
cache/cache_acceptor.c  318  Info 830: Location cited in prior message
                                                                  _
			i = accept(ls->sock, (void*)&wa.acceptaddr,
cache/cache_acceptor.c  458  Error 64: Type mismatch (arg. no. 2) (union
    __SOCKADDR_ARG = void *)

There is one more in cache/cache_backend_probe.c

As the purpose of VSA is to avoid exactly this kind of trouble, we
provide a VSA-wrapper for getsockname.

needed on FreeBSD

This reverts commit 19586003.

My intention behind c021fbca was that
flexelint complains about symbols being defined multiple times.

Yet when we omit all vmods, we end up with lots of 759 (could be moved
from header to module).

So add back vmod_debug and have that refer more of the API.

Without BUILT_SOURCES, we need explicit dependencies

Now that all VMOD sources are prefixed consistently we no longer need to
maintain the lists manually.

We no longer need a special per-VMOD case since we now have one unified
VMOD test suite.

This will improve the build parallelism, and will allow us to run the
VMOD test suite after the main one.

Anything left that would prevent two VMODs to live in the same $(srcdir)
because it would be defined more than once.

Incidentally, defining the variable in the boilerplate makes the
boilerplate unusable out of tree since it assumes vmodtool is in
$(srcdir) which is a show stopper for third party VMODs.

In practice, we only tweak vmod_debug's build for coverage purposes.

Another option could be to have a VTC running vmodtool.py with various
VCC inputs but we currently don't have test coverage for our python
scripts.

That will hopefully not break macos this time.

Refs 8b791930

We can't have more than one test suite if we put all VMODs in the same
directory.