[BUG] PVPN_WAIT causes connections to fail when kill-switch is enabled

[analoginterface0]

If kill-switch is enabled and PVPN_WAIT is set to any positive integer value, protonvpn-cli tries uselessly till WAIT time is reached for establishing a connection although connection shall never establish anyway.

For more technical evidence, this is caused by the code at cli.py:106. It's no brainer to understand how that code affects.

To Reproduce Steps to reproduce the behavior:

1. Enable Kill switch
2. Set PVPN_DEBUG=1 to see the logs.
3. Set PVPN_WAIT to any value greater than 0
4. Issue pkill -x openvpn to artifice an abnormal connection drop.
5. Gaze at the logs
6. See pvpn being looped at Waiting 'x' seconds for connection Initiating api call: https://api.protonvpn.com/test/ping untill PVPN_WAIT time is reached.
7. The connection shall never establish. Only way out is to manually hit protonvpn disconnect

My point Why should kill-switch block the pvpn-cli itself and its internal affairs? What it'd be doing basically is that, locking itself inside doors and swallowing keys afterwards. Instead, a better approach would be to

1. whitelist a specific api address/ip address (like api.protonvpn.com^); although this poses a security problem in case it is enough for a malware/advisory to know he's behind a vpn.

2. whitelist the whole app (alert almost at red-level)

3. whitelist call_api() only? Maybe run some spaghetti coding to fake the real use of the function?

However, this env variable, PVPN_WAIT, works as expected (wait for network to be usable) when started afresh but not when a kill switch is already enabled. This one point takes it into consideration:

4. Use some logic with the PVPN_WAIT thing. For example, look for any connected valid network device (like eth0, wlp2s0, etc, but not lo) and whether any TUN device named proton0 is available.

=> If there's a valid connected device and no proton0 device, and if connection isn't working then wait till PVPN_WAIT.

=> However, if there is a proton0 device regardless of any valid device exists, [there must have been an abnormal disconnect from vpn lately. Maybe the internet was cut off intentionally/unintentionally] initiate a disconnect (a ready solution at hand) and then wait till PVPN_WAIT.

=> IF there isn't any valid device connected, I don't know whether it is logical to wait at all. This keeps a door open though for, let's say, kernel or system manager bugs and all.

5. insert your great idea here

Major Request Remove the PVPN_WAIT line from USAGE.md#via-systemd-wait until this is fixed. Some users may suffer from this if they choose to use kill-switch.

I hope this helps