If the .via field is also set, then the value of .authority is set
as the authority TLV in the PROXY header. This gives the "true"
backend (usually the ssl-onloader) the opportunity to set the SNI
(HostName field) from the TLV value, for the TLS handshake with the
remote backend.

This mandates that PROXYv2 is always used with a via backend (since
only version 2 supports TLVs).

If the value of .authority is the empty string, then the TLV is not
sent. If .authority is not set for the backend, then fall back to
.host_header, which itself may have been a fallback to .host. Note
that if neither .authority nor .host_header is set, and .host is
set to an IP address, then the IP address is forwarded as the SNI
value, which is not permitted for HostName (RFC4366 ch 3.1). So
users are advised to set either .authority or .host_header, or set
.authority="", when .via is set.

Usage note with haproxy:

To enable sending SNI when haproxy is used as a TLS onloader, ``sni
fc_pp_authority`` needs to be used with the backend configuration.

Full usage example with haproxy 2.2:

listen sslon
	mode	tcp
	maxconn	1000
	bind	/shared/varnish_haproxy/haproxy_sslon accept-proxy mode 777
	stick-table type ip size 100
	stick	on dst
	server	s00 0.0.0.0:443 ssl ca-file /etc/ssl/certs/ca-bundle.crt alpn http/1.1 sni fc_pp_authority
	server	s01 0.0.0.0:443 ssl ca-file /etc/ssl/certs/ca-bundle.crt alpn http/1.1 sni fc_pp_authority
	# ...

A higher number of servers improves TLS session caching.