Caddy: Configurable `FallbackDelay` for reverse proxies

[ghost]

This issue is somewhat related to a PR I made recently (#2305) where the default dialer that's created for reverse proxies needed the DualStack field set to true.

The reason I was looking into the issue raised in that PR was because response speed matters to me a lot, and DualStack being enabled really helps to bring responses to a somewhat acceptable level.

Having said that however, if Caddy could provide an extra bit of configuration for the FallbackDelay value in the net.Dialer instance then it would really help people like me tune servers to respond even faster when the response time really matters.

FallbackDelay is only used when DualStack is enabled, which since my PR it now is for reverse proxies.

When the FallbackDelay value is not set the fallbackDelay function in the standard library returns 300 * time.Millisecond as a default.
Because of this, any use of a transport with the net.Dialer's DualStack field set to true always takes at least 300ms after the timeout set in the TLSHandshakeTimeout has passed, or for any new connection.

I've been using Caddy for quite some time now, and always wondered why I would see these spikes in response time, and now I know it's because of this setting.
It would be useful to make the FallbackDelay configurable for those users (like me) where having spikes of at least 300ms delay either feels like a constant thorn in my side, or in some cases, completely unacceptable.

Currently I'm manually setting it to a more reasonable value for my applications by hard coding it myself and building from source, but a new directive would be a much nicer way to solve the problem.

Since this directly relates to reverse proxies (in my case) and reverse proxies are the only place I can see in the source that use a custom dialer anyway, I thought perhaps a new sub-directive in the proxy directive could work.
It also looks like configuration is set per reverse proxy as well, so I'm under the assumption it wouldn't be too difficult to add this.

Does this sound like an acceptable change, and if not what would be the issues with it?

[tobya]

Personally I cant see why if you provided a PR allowing fallbackdelay to be configured via the caddyfile that we wouldnt be able to approve it.

Add it as a new PR and we'll take it from there.

[magikstm]

PR #2309 added this feature.

I think this issue can be closed.

[mholt]

Appreciating the triage work, @magikstm! Do you want to be made a collaborator?

[magikstm]

Sure. I would like to be one.