[CLOYSTER-130] Do not allow choosing the internal NIC when selecting the external

[arthurmco]

Remove the selected internal NIC when presenting a list of possible external interfaces.

Also remove the act of selecting an interface (and filling the parameters) from saving them to the model, to allow a better error handling later.

Also remove conflicts that happen when we run the software twice, of connections already existing, by deleting the old before creating the new one.

[sonarcloud]

Quality Gate passed

Issues
2 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[dhilst]

Also remove conflicts that happen when we run the software twice, of connections already existing, by deleting the old one before creating the new one.

We'll need almost everything that can be done in the cluster to be idempotent. I usually use Idemp suffix to clarify that something should be idempotent. I would suggest an idempotent abstract class, but I don't know if it is too early. Something like (in pseudo code)

class Idemp {
  bool check() = 0;
  void doit(args) { if check() { return; } else /* do stuff */ }
}

I'm afraid of using inheritance for that, I don't know if we can have a compositional way of expressing this. Maybe using concepts?

[dhilst]

idempotent

Just to make it clear, by idempotent, in this case, I mean "doing something twice yields the same result". For example, enabling the same service twice should be the same as enabling the service once. Adding the same address to the same network twice should be the same as adding that address to the network once.

In general, for any task T, doing T(), T(); T(), T(); T(); ...; T() should be the same.

It makes things easier too if for each task T we have an inverse that undoes T, let's say R, so that T(); R() puts the system in the same state it was before. So T(); R(); T() is the same as T(), and R should be idempotent too so T(); R(); R(); T(); is the same as T(); R(); T(), which is the same as T().

The motivation is that, if we have these properties (idempotency and inverse) we do not have to worry about the order things are executed, they all converge to some predictable state. If I have a task P that depends on T I can just call T() in Q and if P depends on T too I can just call it again, P and Q can be executed in any order, and doesn't need to know on each other. The inverse is one way of achieving idempotency, but it may not always be possible, for example, you cannot delete the hostname of a machine, only change it, so there is no reverse for setting up a hostname, adding an IP address to a network has an inverse.