Undeploy cluster with termination of peer network

[mirenz1]

Currently the undeploy function only changes the deployment status in CARL, but does not destroy the actual network (#287 ) that was setup during deployment. When a cluster is undeployed the network connections shall be disconnected.

Actions for cluster undeployment:

• inform EDGAR about undeployment Set PeerConfiguration2 parameters as Absent.

  • Migrate remaining parameters from PeerConfiguration to PeerConfiguration2.

• EDGAR removes executor container if exists

  • Extend EDGAR Task concept to offer an unapply().
  • Use EDGAR Tasks in EDGAR Service.

• EDGAR keeps configured network bridges on the peer (as is right now), when a cluster is deployed, the bridge is removed and newly created

• EDGAR terminates cannelloni

• EDGAR service and netbird client keeps running after undeployment

depends on #199

[mbfm]

Without this, it is not possible to define an executor and then deploy a cluster twice.

Error printed out by Docker after being started by EDGAR:

Error: error creating container storage: the container name "asdas" is already in use by "8eaf0a20abbdcf6fc389f364fe07d767d0fbb7ec09b9fdd79514fab90940c375". You have to remove that container to be able to reuse that name.: that name is already in use

This is currently not made transparent to the user. We'd need to implement #207 for that.

[mbfm]

• EDGAR should handle all Absent rules before handling the Present rules, to ensure no conflicts in configurations occur.

• EDGAR needs to detect when a Parameter is still Present, but the actual OS configuration needs updating, when the value of the Parameter changed.
  This means, any time EDGAR receives a new PeerConfiguration, it needs to go through all Tasks and run check_fulfilled() (or check_present() and check_absent(), as they will probably be renamed). The PeerConfiguration only represents the target state, so it's up to EDGAR to detect changes.
  In particular, we don't want EDGAR to remember its previous state, because this can be wrong.
  Nor do we want to give each Parameter an incarnation and then Absent the previous incarnation + Present the new incarnation, since this would mean EDGAR could only be told to e.g. remove a network interface and then recreate it with the new configuration, rather than simply updating the configuration of the existing interface.

(Noticed these points while fixing #319.)