GetCurrentNS doesn't always return the "current" netns

[tnqn]

We use ns.WithNetNSPath and ip.SetupVethWithName to set up container networking in CNI plugin Antrea. Recently we found a bug antrea-io/antrea#1113 that some Pods' network interfaces were not in the host netns after restarting Worker Nodes. The network interfaces were finally found in other Pods's netns, and we think it's because of a race condition in GetCurrentNS. @antoninbas had a good description about how it happened: antrea-io/antrea#1113 (comment).

The fact that It doesn't happen to other CNIs might be because Antrea has a long running daemon processing all CNI requests and executing the above steps. So if the race condition happens, the "hostNS" might have been another container's netns.

We use this library widely in our project and would appreciate this could be fixed from upstream side. This is a potential fix for it: #523.