Please do not assume this to be complete since 5.2 release

Please do not even assume my XXXes to be completely referencing the missing bits.

Waving @slimhazard / Geoff from the ICE train and Berlin U-Bahn/S-Bahn

I wonder if maybe varnishd start should not return before accepting?

Ref: 6cb21b47
     #2382

Afterthought on #2405:

The usage pattern we want to get to is (pseudo vcl, don't take
the syntax for granted)

	sub vcl_whatever_client_sub {
		std.rollback(req);
		set req.<whatever>;
		...
		return (restart);
	}

The hash and storage controls should be no exception

Rewrite the CLI command acceptance to not use the VLU functions,
but a small state machine.

Unauthenticated CLI sessions have a hard limit of 80 char cmds
and cannot use the "<< nonce" construct.

... not for any vsm change.

Fixes #2430

Merges #2447

Fixes #2405 for restarts
Merges #2447

remaining TODOs (but not the scope of this ticket):

* Keep bereq attributes for bereq
* improved rollback

I see absolutely no reason why we shouldn't allow read access outside
vcl_recv

Merges #2447

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