This generally seems to be the wrong knob to protect against runaway
forks (as it does not limit per instance, but per user systemwide), but
a general mediation is still under discussion. Meanwhile bump the limit
for the Debian unit to 100.

Upstream openvpn-client@.service and openvpn-server@.service still use
10

See Bug#861923 for discussion.

Same change has been done upstream in 2.4.7

Closes: #868806

This copies a change in the upstream systemd unit into the Debian-specific
one

===
systemd: Ensure systemd shuts down OpenVPN in a proper way
By default, when systemd is stopping OpenVPN it will send the SIGTERM
to all processes within the same process control-group.  This can come
as a surprise to plug-ins which may have fork()ed out child processes.

So we tell systemd to only send the SIGTERM signal to the main OpenVPN
process and let OpenVPN take care of the shutdown process on its own.

If the main OpenVPN process does not stop within 90 seconds (unless
changed), it will send SIGKILL to all remaining processes within
the same process control-group.

This issue have been reported in both Debian and Fedora.

Trac: 581
Message-Id: <20170906234705.26202-1-davids@openvpn.net>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg15369.html
Signed-off-by: David Sommerseth <davids@openvpn.net>
[DS: Applied lazy-ack policy]
===

Adjust openvpn@.service to be similar to the upstream
openvpn-server@,service

In detail:
* Adjust Documentation URL to OpenVPN 2.4
* use systemd READY signalling (Type=notify)
* add ProtectHome=true
* Add After/Wants network-online.target, this should fix a few
  bugs happening due to OpenVPN starting too early
* adjust CapabililtyBoundingSet

Closes: #858558, #864031