dco-linux: iroutes disappear in case of quick client reconnect

CONTEXT

When using DCO on Linux or BSD, iroutes are implemented by adding standard routes in the system table, having the client VPN IP as nexthop. This entries help DCO later to figure out which peer to send the traffic to.

THE ISSUE

OpenVPN process client exits in a two step fashion: first the exit/timeout is detected and a purge routine is scheduled for execution after 5 seconds. Then the timer fires and the actual purge is performed.
The DCO iroutes are deleted by the delayed purge routine.
If a peer (with iroutes configured) quickly disconnects and reconnects using the same username and gets the same IP assigned, then it will race with the delayed exit routine.
Specifically the following will happen:

• client disconnects, purged scheduled after 5s
• client reconnects immediately (within 5s) and a new instance is created
• DCO iroutes are installed, but that fails with EEXIST
• 5s timeout fires -> DCO iroutes are removed (thinking they belonged to the previous client)
• new client is fully connected, but no iroutes are in place

This behaviour exists since 2.6.x.

STEPS TO REPRODUCE

1. provision a client, say client1
2. create a ccd folder with client1 containing two entries:

ifconfig-push 10.10.0.3 255.255.255.0
iroute 8.8.8.8

The first one ensures the client always gets the same IP (picked within the server pool for simplicity).
The second one is just a random iroute to be used to demonstrate the bug.
3. launch the server with --client-config-dir and --duplicate-cn to ensure a new instance is created when the clients reconnects.
4. start the client with --explicit-exit-notify and wait for connection
5. check the system table for the iroutes
6. disconnect the client and reconnect immediately
7. watch the server to observe the behaviour described above
8. after 5s check the routing table to see the iroutes being gone

Start with the DCO iroute installation and the delayed purge routine described in the issue, then reproduce the quick disconnect/reconnect sequence using the listed client configuration and routing-table checks. Done means a reconnect with the same assigned IP retains the DCO iroutes after the delayed purge runs.