networkmanager returns null keys for some connections.

[dforste]

There are some cases where a connection is returned without a device attached.
Eg.

# nmcli -t connection show
System ens160:ea74cf24-c2a2-ecee-3747-a2d76d46f93b:802-3-ethernet:ens160
lo:04577901-581b-4cac-bb04-f015fe36274d:loopback:lo
ens160:5780e094-7abe-419a-9c3e-de716150898d:802-3-ethernet:

In this case the key is empty string. I suggest using the name as the ID and creating a device below it.

The current behavior:

# facter -p simplib__networkmanager.connection
{
     => {
      name => "ens160",
      type => "802-3-ethernet",
      uuid => "5780e094-7abe-419a-9c3e-de716150898d"
    },
    ens160 => {
      name => "System ens160",
      type => "802-3-ethernet",
      uuid => "ea74cf24-c2a2-ecee-3747-a2d76d46f93b"
    },
    lo => {
      name => "lo",
      type => "loopback",
      uuid => "04577901-581b-4cac-bb04-f015fe36274d"
    }
}

Proposed behavior:

# facter -p simplib__networkmanager.connection
{
    ens160 => {
      device => "",
      name => "ens160",
      type => "802-3-ethernet",
      uuid => "5780e094-7abe-419a-9c3e-de716150898d"
    },
    System ens160 => {
      device => "ens160",
      name => "System ens160",
      type => "802-3-ethernet",
      uuid => "ea74cf24-c2a2-ecee-3747-a2d76d46f93b"
    },
    lo => {
      device => "lo",
      name => "lo",
      type => "loopback",
      uuid => "04577901-581b-4cac-bb04-f015fe36274d"
    }
}

[RamblingCookieMonster]

+1, as this issue is a bit dated. We have some folks who want to use a puppet module depending on this, and the resulting facts json makes a few downstream processes unhappy. We can deal, but, it seems less than optimal as is, using the name seems like a reasonable fallback.

[dforste]

#290