Add connect-freq-initial option to limit initial connection responses

Add connect-freq-initial option to limit initial connection responses

This limits the number of packets OpenVPN will respond to. This avoids
OpenVPN servers being abused for refelection attacks in a large scale
as we gotten a lot more efficient with the cookie approach in our
initial connection handling.

The defaults of 100 attempts per 10s should work for most people,
esepcially since completed three way handshakes are not counted. So
the default will throttle connection attempts on server with high packet
loss or that are actually under a DOS.

The 100 per 10s are similar in size to the old 2.5 and earlier behaviour
where every initial connection attempt would take up a slot of the
max-clients sessions and those would only expire after the TLS timeout.
This roughly translates to 1024 connection attempts in 60s on an
empty server.

OpenVPN will announce once per period when starting to drop packets and
ultimatively how many packets it dropped:

    Connection Attempt Note: --connect-freq-initial 100 10 rate limit
    exceeded, dropping initial handshake packets for the next 10 seconds

    Connection Attempt Dropped 217 initial handshake packets due to
    --connect-freq-initial 100 10

to inform an admin about the consequences of this feature.

Patch v2: use strtol instead of atoi to be able to differentiate between
          an error parsing and parsing 0. Use int64_t instead int to
          avoid overflow errors.

Patch v3: Add message when we start dropping. Add a few fixes to the logic.
          improve docs

Patch v4: missing missing return statement.
Patch v5: add build files for msvc build

Signed-off-by: Arne Schwabe <arne@rfc2549.org>
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <20230110015901.933522-1-arne@rfc2549.org>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg25938.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>