Handle ENOBUFS when sending data

[roop]

Attempts to resolve passepartoutvpn/passepartoutkit#34.

When we have too much data to send (like during the upload phase of a speedtest), we encounter ENOBUFS ("No buffer space available") errors like this:

2021-10-18 14:32:43.529 ERROR OpenVPNSession.sendDataPackets():1181 - 
Data: Failed LINK write during send data: Error 
Domain=NSPOSIXErrorDomain Code=55 "No buffer space available"
2021-10-18 14:32:43.529 ERROR OpenVPNSession.doShutdown():1280 - Trigger 
shutdown (error: failedLinkWrite)
2021-10-18 14:32:43.530 ERROR OpenVPNTunnelProvider.sessionDidStop():599 
- Session did stop with error: failedLinkWrite
2021-10-18 14:32:43.530 ERROR OpenVPNSession.loopLink():410 - Failed 
LINK read: Error Domain=NSPOSIXErrorDomain Code=89 "Operation canceled"
2021-10-18 14:32:43.530 DEBUG 
NEUDPSocket.observeValueInTunnelQueue():147 - Socket state is cancelled 
(endpoint: 145.100.179.14:1201 -> 145.100.179.14:1201)
2021-10-18 14:32:43.530 INFO OpenVPNSession.cleanup():334 - Cleaning up...
2021-10-18 14:32:43.531 ERROR 
OpenVPNTunnelProvider.finishTunnelDisconnection():370 - Tunnel did stop 
(error: failedLinkWrite)

To handle this scenario, this PR:

• Restructures reading from the TUN interface (data to be sent out), so that the next read is scheduled only after the previous read is handled successfully.
• On encountering ENOBUFS, waits for 1 second, then attempts to send the data again. Only after the data is sent without errors does it trigger the next read from the TUN interface.

In my testing, this keeps the connection stable during the upload phase of speed tests. I don't see any noticeable reduction in upload speed.

I understand this might need a detailed review (especially commits 7f87f9f and f220ebf), so please take your time.

[keeshux]

I'm closing this for three reasons:

• The PR is probably outdated at this point
• I see you reverted it later
• I plan to rethink the fragile tunnel's synchronization with Swift Concurrency instead

I'll certainly take into account the considerations from this PR, so thanks!

[roop]

We reverted the revert later as well -- we identified an issue that was masked by this issue and fixed that: https://github.com/eduvpn/apple/pull/484.