Conflicts:
	bin/varnishd/cache/cache_req_fsm.c
	include/tbl/vsl_tags.h

Other SLTs were back-ported as well, but marked as not supported, to
ensure binary forward compatibility up to 6.2 releases.

And we have a goal of making the VSL self-documenting so reordering
anything is pointless. We already reorder SLTs in the documentation
where sorting really matters to end users.

When a VMOD returns a STRANDS, it is a requirement that the storage
be stable, but that is not really different from any other type of
return value.

Completes #2873

Strenghen the case against STRING_LIST in the docs.

See also: #2873

Conflicts:
	lib/libvmod_debug/vmod.vcc

Conflicts:
	lib/libvmod_blob/hex.c

Re-implementations of the current functions for STRING_LIST.

Closes #2733

Conflicts:
	include/vrt.h
	lib/libvmod_debug/vmod.vcc
	lib/libvmod_debug/vmod_debug.c

This introduces VRT 7.1 for the 6.0 releases.

Fixes #2846

Fixes #2880

Fixes #2879

This has bugged me (slightly) for ages.

Too trivial to warrant its own line(s) in test-case/u00008.vtc.

Should address "HTTP cache must not reuse a response with an invalid
Cache-Control: max-age (trailing alpha)" from https://cache-tests.fyi.

Should address "HTTP cache must not use a cached response with
Cache-Control: No-CaChE, even with max-age and Expires" from
https://cache-tests.fyi.

Fixes: #2874

Fixes #2871.

Conflicts:
	bin/varnishd/cache/cache_fetch.c

Submitted by:   Frederic Lecaille <flecaille@haproxy.com>

It turns out people are really attached to their varnish.params file.

See `git grep PROXY -- bin/varnishd/mgt/mgt_main.c`.

A regression from d7a81fe8 and the
followup changes from #2993. The new VSS_Resolve{One,First} functions
expect a non-null address string.

Conflicts:
	lib/libvmod_std/vmod_std_conversions.c

Conflicts:
	lib/libvmod_std/vmod.vcc

Conflicts:
	bin/varnishtest/tests/m00011.vtc
	lib/libvmod_debug/vmod.vcc
	lib/libvmod_debug/vmod_debug.c

And sync the documentation with the current behavior, part of which used
to be implicit.

Conflicts:
	lib/libvmod_std/vmod.vcc
	lib/libvmod_std/vmod_std_conversions.c

Conflicts:
	lib/libvmod_std/vmod_std_conversions.c

This is how std.ip is documented, so VSS_ResolveOne doesn't work there.
It might not be the only migration to VSS_ResolveOne that requires
attention.

Speaking of attention, VSA_Malloc may require some.

Conflicts:
	lib/libvmod_std/vmod_std_conversions.c

It can now be shared by established callback-based resolvers and the new
VSS_ResolveOne. This also changes the semantics of VSS_ResolveOne in the
sense that the port is now a default port, overriden by the address if
it contains one.

Also make it clear that VTCP was already relying on a VSS function that
didn't and still doesn't allow a null errp argument, while conversely
all VTCP_open call sites provide a valid errp argument.