The algorithm for attaching to existing DRBD devices is not trivial. It
has four alternatives, and there is a bug in the last one when we have
diskless devices.

The last case (local disk info matches but remote/network configuration
doesn't match) we disconnect from the network and reattach with the
correct info. We do this because correct local device has higher
priority than remote device.

However, the test we use (self._MatchesLocal) can succeed in two cases:
  - we have a disk and it's the same as the one attached
  - we don't have a disk and the drbd is in diskless mode

But this creates problems for the fourth case as when we already have
one diskless DRBD, activating then next one will do:
  - _MatchesLocal? yes, because both config data and system have no
    disks (with the effect that all diskless devices are identical)
  - _MatchesRemote? no, because this disk is configured to its current
    remote peer, not to our new one

The fix is trivial, although the algorithm not: we only allow overriding
the network configuration when the disk information matches and we are
not diskless, by adding the <"local_dev" in info'> test.

Reviewed-by: ultrotter