device: add logging macro _LOGT()
device: don't fail activation when IP config is unavailable and unneeded

If we didn't start IPv4 and IPv6, but they're allowed to fail, progress
the activation without failing it. Also, progress assumed connections to
check-ip with whatever configuration that is available.

https://bugzilla.redhat.com/show_bug.cgi?id=1141264
platform: ensure all objects in link cache are of AF_UNSPEC family

We assume that in nm_nl_cache_search() and correctly set that in
get_kernel_object(), but we rtnl_link_alloc_cache() can initialize the cache
with devices of other families.

The consequence is that we don't notify when the bridge changes to IFF_UP as we
fail to match and remove the old downed object from the cache:

  nm_device_bring_up(): [0xf506c0] (bridge0): bringing up device.
  nm_platform_link_set_up(): link: setting up 'bridge0' (12)
  link_change_flags(): link: change 12: flags set 'up' (1)
  get_kernel_object(): get_kernel_object for link: bridge0 (12, family 7)
  log_link(): signal: link   added: 12: bridge0 <UP> mtu 1500 bridge driver 'bridge' udi '/sys/devices/virtual/net/bridge0'
  get_kernel_object(): get_kernel_object for link: bridge0 (12, family 7)
  log_link(): signal: link changed: 12: bridge0 <UP> mtu 1500 bridge driver 'bridge' udi '/sys/devices/virtual/net/bridge0'
  log_link(): signal: link changed: 12: bridge0 <UP> mtu 1500 bridge driver 'bridge' udi '/sys/devices/virtual/net/bridge0'
  (bridge0): device not up after timeout!
  (bridge0): preparing device
platform: refactor the object comparison logic into a separate function

One from libnl is not good enough (see comment).
platform: resynchronize with kernel when we're out of buffer space

Kernel can return ENOBUFS in variety of reasons. If that happens, we know we've
lost events and should pick up kernel state.

Simple reproducer that triggers an ENOBUFS condition no matter how big our
netlink socket buffer is:

  ip link add bridge0 type bridge
  for i in seq $(0 1023); do ip link add dummy$i type dummy; \
    ip link set dummy$i master bridge0; done
  ip link del bridge0
Revert "platform: increase NL buffer for systems with lots of interfaces (rh #1141256)"

This reverts commit efd09845c41e08469d6f6bffa23bd90b6bd06e85.

It turns out that the socket space might not be the only buffer that may get
too full. 128K ought to be enough for it and we should resynchronize with the
kernel now if needed.
device: release and enslave an interface if its master changed

In case of an atomic master change, we'd not notice that the master changed:

  ip link set dummy0 master bridge0
  ip link set dummy0 master bridge1
device: set the master on device addition

Otherwise we won't notice the device is a slave on NM startup until someone
changes the link or tries to activate the device.
device: assume connections for device with slaves

If a bridge/team/bond has slaves, assume it's connected. Recheck as devices
appear.

https://bugzilla.redhat.com/show_bug.cgi?id=1141266
agent-manager: don't ever fail the secrets requests from GetSecrets()

VPN connections always return true for nm_connection_need_secrets(), but the
documented behavior of GetSecrets() is just to return any secrets we have
(otherwise nmcli c --show-secrets would not be useful for VPN connections).
core: don't wipe out VPN secrets if we're changing the connection

The VPN secret properties are hashes and thus the default property value does
not work with them.
cli: expose the vpn.persistent property
cli: assert that there's an GError in case of an error in parse_output_fields()

parse_output_fields() crashes if it encounters an error (nonexistend column)
and it is called with error == NULL. That should never happen, as it's never
called with NULL error against user input. However, it is useful to assert
that is the case -- it gives us a more useful crash in case of a programmer
error.
Merge remote-tracking branches 'fd/lr/veth-managed', 'fd/lr/no-udev', 'fd/lr/vpn-fixes' and 'fd/lr/bridge-rh1141266' into integration