support for dummy interfaces

I have a customer who is migrating their cloud from Xenial/Mitaka to Bionic/Queens, and has begun the exercise of migrating their network topologies to netplan, but found that it does not support creating dummy interfaces (or, apparently support for OVS at this point[0]).

There is a bit of a workaround using a systemd unit, which may close the gap temporarily, but it may not apply to all environments (pseudocode below)

[Unit]
Description=Create dummy interface
After=network.target

[Service]
Type=oneshot
ExecStart=/sbin/ip li add dummy0 type dummy

I'd like to see native support in netplan for dummy interfaces, if possible.

[0] https://bugs.launchpad.net/netplan/+bug/1728134

Indeed, it would be handy to have support of dummy interfaces.

In the WWW, I have seen _workarounds_ like this:

```
network:
  version: 2
  renderer: networkd
  bridges:
    dummy0:
      interfaces: []
      addresses: ['10.111.222.60/24']
```

but a bridge is not a dummy interface.

FYI, my workaround is the following:

```
    bridges:
        loop1:
            dhcp4: no
            dhcp6: no
            accept-ra: no
            interfaces: []
            addresses: ['A.B.C.D/32']
```

# ethtool -i loop1
driver: bridge
version: 2.3
firmware-version: N/A
expansion-rom-version:
bus-info: N/A
supports-statistics: no
supports-test: no
supports-eeprom-access: no
supports-register-dump: no
supports-priv-flags: no

It is not exactly equivalent to:

sudo ip link add name loop1 type dummy
sudo ip addr add A.B.C.D/32 dev loop1

but it does the job.

That's why a proper fix is not top priority, but it would be a nice to have.

Loopback interfaces are important for switches/routers. The Linux dummy interface provides the ability to create interfaces whose function is consistent with loopback interfaces widely used on switches/routers.

Dummy interfaces can be created with both Network Manager and systemd-networkd. Because of their simplicity, adding support to netplan should be easy and will not add debt to the netplan project. The nmstate project already supports dummy interfaces. There is no practical need to match or sync with any existing devices on the system. Netplan should not concern itself with anything but creating the interface and assigning the addresses.

There are very important uses for dummy/loopback interfaces.

- Link-State routing protocols like OSPF/IS-IS, or cluster identifier for iBGP
- Endpoints for systems with multiple tunnels
- Any situation where a layer-3 failover solution is required
- Load balancing with ECMP (equal-cost multipath routing)
- Configuring additional addresses on system which are being routed to the system via a physical interface from an upstream internet/cloud/hosting provider.

A dummy/loopback interface is NOT a bridge. A bridge is a layer-2 solution, a dummy/loopback is a layer-3 solution.

The proper location in the yaml hierarchy should be:

network:
  dummies: # or loopbacks:
    dummy0:
      addresses:
        - n.n.n.n/n

A bridge interface is not a great substitute for a dummy/loopback interface because it can complicate configurations and create confusion for users. In most bridge implementations, the bridge includes a physical interface for connectivity to an external gateway. During troubleshooting, it is very common for users to be misled into thinking they need to add their physical interface to the bridge and migrate the IP configuration to the bridge which solves nothing and usually results in additional problems.

FYI a bridge interface will report link state down until the first device is attached to it. At least with FRR this will prevent the IP attached to the bridge interface from being advertised.

@Francois Lafont comment says a lot of thing "a bridge is not a dummy interface."

It doesn't work how dummy interface shall work. Somehow it truncates packets and broke struct. I will give a try about "systemd unit"

Pull request implementing support for dummy interface for review https://github.com/canonical/netplan/pull/361