Need to handle existing OPTE port names

[bnaecker]

We use an atomic counter to create unique names for OPTE ports, done here. It's possible that this name conflicts with an existing data link, but that the link does not show up in dladm output (which we use to clean up any old links when the sled-agent starts). In that case, we will get an EEXIST from the call to create_xde.

There are a few options. We can just skip the name as long as we get EEXIST, or we can update the xde driver to forcibly remove or overwrite that existing name. The latter is based on the assumption that if we get a link that we cannot see with dladm, it's by definition a leaked resource that can and should be clobbered. It's not yet clear who should do the clobbering (xde or sled-agent), or how they'd do that. One reason to take option one (skipping the name) is that this would preserve the system state for debugging and forensics.

[rzezeski]

I don't think having xde create/delete link IDs makes sense. It's a kernel driver, and link IDs are managed in userland via door calls to dlmgmtd. It could happen in opte-ioctl, but I'm not sure having this implicit behavior makes sense, as the link could be a legit active port (remember, in the future OPTE may have other consumers than sled-agent). If you want to do this it feels very much like a control plane matter -- as that's where we have full knowledge that this is a defunct link.

[bnaecker]

@rzezeski Agreed, @rcgoodfellow and I came to the same conclusions when we talked more about it.