This should have gone with d9a9ecd9

Somehow I was unable to see that the code did not actually do what I
thought (and documented) it would do.

Fixes #2470

a vav[0] is the error or NULL if ok. vsm_cmp_av considers NULL the end
of the av, so we would always comare vg and the av equal and begin insertion
of new vgs. This would lead to all vsm segments be removed and newly added.

Fixes #2470

vmod_vtc might be a better place for it, but we should probably get $VSC
support in vmodtool first and generate the am_boilerplate for it.

Ref #2470

Somehow this comment has survived even though we don't use BUILT_SOURCES
here any more

I did consider avoiding locks, but as long as the close() in VCA_Shutdown()
happens concurrent to vca_acct(), the file descriptor could become invalid
at any time, so even if we'd not hit the sock > 0 assertion, other errors
could occur / assertions be hit.

We could also move the close to vca_acct() and just signal it to finish off,
but this would delay the close by the sleep(1), unless we further complicated
things with a condvar.

Avoiding the lock would require us to make any operation on a socket fd
ignore errors, which is totally against our policy to assert on everything.
(see vca_tcp_opt_set() for example).

So, for the time being, I think simple serialization using a pthread mutex
is the safest and simplest solution. A varnish lock would be overkill, as
this lock is really only relevant during VCA_Shutdown.

IMHO, the primary risk involved here is delayed VCA_Shutdown() due to
vca_acct() hanging in a syscall. Famous Last Words - sigh.

Fixes #2482

Relates to #2480

We were tolerating some unintentional ESI behaviour due to the
xml check hitting.

We now either avoid running into the xml check or specifically
test that we are hitting it.

In addition, add some logexpects to tighten checks

ver_p depends on the amount of data we have read ahead, so it is not
suitable to get predictable results for ESI testing

for the default symbolname prefix ("vmod_")