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

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)