feature request: make control-channel explicit-exit-notify fast

[cron2]

copy-paste from IRC

15:56 <@ordex> cron2: what is there to fix for poor Giaan ? :D 15:57 < Giaan> ordex: I guess he wants --een to be faster 15:58 <@cron2> yes :-) 15:59 <@cron2> giaan is the event god of OpenVPN now 16:00 <@ordex> but it's not a regression, isn't it? 16:01 < Giaan> cron2: I don´t think this is related to the event loop tbh, aren´t we back to 2.6 levels? 16:01 <@cron2> Giaan: we are, so it's not an "multi event" thing 16:02 <@cron2> but it still sucks :-) - non-control-channel een is "instant" and cc een is "2.5s", which I could see on the server ("send out all these tls packets and wait for ack from all these clients") but on the client, waiting for an ack to a goodbye packet might be a bit overdoing it... so I think if we get an ACK for the cc een, we should be able to terminate right away 16:03 <@cron2> and on the server, if there are no clients or all clients have ACKed, exit right away 16:03 <@cron2> ... and if it turns out that that we do not even ack an incoming EEN, exit without waiting 16:04 <@cron2> (to make it clear: this is neither ordex' nor giaan's doing, but you might understand this enough to fix it ;-) - otherwise plaisthos needs to dive in again, and we will see a 20-patch series fixing all of it) 16:05 * ordex feels this is a 4 months project 16:05 <@ordex> :D 16:05 <@cron2> ordex: schneller arbeiten 16:05 <@ordex> 2 days to get the code done, 3 months of debugging 16:05 <@ordex> :D 16:06 <@ordex> cron2: can you create a ticket for this? so we don't forget?

also somewhat related to #702 (where CC EEN led to a delay of 10+ seconds due to not checking signals often enough)

[schwabe]

normal explicit-exit-notify is only instant if it is 1. explicit-exit-notify 5 will also send 5 packets with 1s spacing iirc.

With EEN we just schedule a disconnect in 3 or 5s (have to double-check code) as otherwise we have to do either super ugly stuff or massive refactoring to have something react on an ack from the server that it is actually received the message.