Setting tls-timeout to 0 (zero) leads to traffic spikes and anomalous behavior

Describe the bug
Inadvertently setting the tls-timeout option to zero generates traffic spikes and anomalous behavior which can stress the underlying network infrastructure.

To Reproduce

This is the config I was using (replaced some sensitive info with asterisks):

nobind
persist-key
persist-tun
pull
tls-client
auth SHA1
ca /etc/x509/ca-1-******.pem
cert /etc/x509/client-*******.pem
cipher AES-128-CBC
dev gw2_staging_udp
dev-type tap
fragment 0
keepalive 10 60
key /etc/x509/key-******.pem
log /var/log/gw2_staging_udp.log
mode p2p
mssfix 0
mute 20
proto udp
remote *********** 1199
reneg-sec 0
resolv-retry infinite
tls-timeout 0
verb 3

Expected behavior

I am not sure why I had set tls-timeout to zero, maybe it was a mistake, it doesn't seem to make sense.
I would expect OpenVPN to let me know if this is a mistake and fail.

However, the daemon starts but cannot initialize the VPN session successfully. In the meanwhile the IT team on the remote site reported anomalous traffic that is causing issues to their firewall and even denying the traffic causes issues. This is probably an issue with their firewall that we are going to report to the firewall vendor, but it's nonetheless something that I wanted to let you know.

If I set tls-timeout to >= 1 the VPN session instantiates successfully and no anomalous traffic is observed.

My impression is that setting this value to zero should not be allowed.

Version information (please complete the following information):

• OS: OpenWrt 22.03
• OpenVPN version: 2.5.7
• Peer: PfSense 2.5.2, OpenVPN 2.5.2

Start by reproducing the provided OpenVPN configuration with tls-timeout set to 0, then trace how that option is parsed and used during TLS session initialization. Compare the behavior with values of 1 or greater. Done means zero is either rejected with a clear error or handled without failed-session traffic spikes, with regression coverage for the case.