Add externally_managed property for NetworkInterfaces

[JoshuaWatt]

Description

Adds a property to NetworkInterface to indicate that the interface is externally managed by the system administrator, and cannot be manipulated by labgrid. While RawNetworkInterfaceDriver has a similar flag, setting a flag at the driver level is suboptimal since not all instances of RawNetworkInterfaceDriver are guarenteed to correctly set that flag. As an example, if labgrid-client or a test script creates a RawNetworkInterfaceDriver ephemerally, it will reset the network interface configuration, much to the consternation of the system administrator.

Checklist

• Documentation for the feature
• Tests for the feature

• The arguments and description in doc/configuration.rst have been updated

• Add a section on how to use the feature to doc/usage.rst

• Add a section on how to use the feature to doc/development.rst

• PR has been tested

• Man pages have been regenerated

[jluebbe]

Hmm, what does this mean for the NetworkInterfaceDriver? It's main purpose is to actively manage a network device. Should it reject resources where the externally_managed flag is set?

A possible alternative would be to disallow some actions in helpers/labgrid-raw-interface based on new config options in /etc/labgrid/helpers.yaml. If we could query the configuration, the RawNetworkInterfaceDriver could detect automatically whether it can/should manage the device.

[JoshuaWatt]

You can kinda work around this by using veth pairs and bridges to give labgrid it's own interface, like so:

     +------+
     | br0  |
     +------+    
     |      |
+------+   +-------+      +-------+
| eth0 |   | veth0 | <--> | veth1 |
+------+   +-------+      +-------+

Then you can admin eth0/br0 and give labgrid veth1 to do with what it will, so perhaps this change is not necessary.

However, it does highlight how annoying it is that rawnetworkinterfacedriver takes the interface up and down; It really makes me wonder if perhaps some of the functionality (in particular the new netns stuff) should not be part of that driver; or at least in our use case having rawnetworkinterfacedriver take the interface up and down whenever some ones labgrid-client netns is going to be a real problem. It also means you can't run multiple labgrid-client netns because anytime one ends it will bring down the interface and the rest will stop working

[JoshuaWatt]

Abandon in favor of #1808