handlers(l4proxy): add use_client_config to l4proxy upstream conf

[legobeat]

The TLS client configuration for proxy upstreams considers the downstream connectino values only if configured empty.

This adds a new configuration value use_client_conf, which allows preserving this behavior despite configuring the tls field.

[mholt]

Hmm, thanks -- I'm trying to understand when this would be useful though? If the server has a TLS client configured, then it is used, otherwise we transparently use the client's TLS config. How can we possibly use both?

[legobeat]

Hmm, thanks -- I'm trying to understand when this would be useful though? If the server has a TLS client configured, then it is used, otherwise we transparently use the client's TLS config. How can we possibly use both?

There might still be different connection options used in the downstream and upstream connections, though? For example, caddy-l4 user may want to override renegotiation or alpn/protocol options but still otherwise fill in from the client? E.g. we may have a currently working config with nil tls where changing anything would be perturbing the default behavior. After this change, the user can couple the new field with use_client_config: true.

Does that make sense?

One potential source of confusion I'm seeing now is that even if use_client_config is explicitly set to false, the default case will still happen and client options get filled in. Do you think it's worth the squeeze (or even desirable) to distinguish between "explicitly set false" (=> never use client options) and "not configured" (=> as today: use client options iff tls is nil)?

[mholt]

For example, caddy-l4 user may want to override renegotiation or alpn/protocol options but still otherwise fill in from the client?

I think I see, so you want to use the client's connection properties but just change one or two of them.

If so, then yeah, the possibility of empty and nil values colliding will be tricky without some annoying changes... hmm.