provider/maas: cater for MAAS 2.1 "bridge" types

[frobware]

On MAAS 2.1 a user can now define bridges. If you do this and
bootstrap then Juju and Mongo consume lots of CPU and RAM as the
machiner repeatedly tries to add a link-layer device (to state) but
fails because linklayerdevies.type is "" (undefined).

We fix this by extending provider/maas's notion of interface types to
handle a "bridge" type. Note: this still seems brittle as we will fail
at the next interface type we don't handle.

QA steps (before applying the patch):

1. In MAAS 2.1 configure a node's PXE interface to be a bridge.

2. juju bootstrap

3. Look through /var/log/juju/machine-0.log for messages like:

... juju/juju/state/machine_linklayerdevices.go:641:
cannot set link-layer device addresses of machine "0"}

... juju.worker.dependency engine.go:608 restarting dependents of "machiner" manifold
... juju.worker.dependency engine.go:422 starting "machiner" manifold worker in 3.05s...

4. Let the machine run for 10 minutes.
5. Run top (or htop) and note the CPU and RAM usage increasing

Now apply the patch and verify that (3) and (5) are golden.

Fixes LP:#1644720

[frobware]

!!retry!!

[voidspace]

LGTM

[frobware]

!!retry!!

[bz2]

!!retry!!

[macgreagoir]

LGTM, but haven't setup the QA tests yet.

[macgreagoir]

QA steps tested successfully to resolve a broken bootstrap machine.

[frobware]

$$merge$$

[jujubot]

Status: merge request accepted. Url: http://juju-ci.vapour.ws:8080/job/github-merge-juju

[jujubot]

Build failed: Tests failed
build url: http://juju-ci.vapour.ws:8080/job/github-merge-juju/9724

[frobware]

$$retry$$

[jujubot]

Status: merge request accepted. Url: http://juju-ci.vapour.ws:8080/job/github-merge-juju