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
core,cli,agent-mangager: merge branch 'lr/vpn-fixes'

Various VPN-related fixes.

https://bugzilla.gnome.org/show_bug.cgi?id=740525
tests: fix setting MAC address in tests

MAC address properties are strings now. The change has been done by commit
3a54d050985d6ef2067b025571910a8ccd3cbd57. But this place was not updated.

Reported by lrintel in copr.
device: turn nm_d_ip_config_should_fail to get_ip_config_may_fail

Has a cleaner semantics and will be useful later on. Also, make it static --
it's not used outside nm-device.c.
device: don't disconnect assumed connections

Transition them to activated status when they fail.

https://bugzilla.redhat.com/show_bug.cgi?id=1141264
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
device: merge branch 'lr/assumed-activation-rh1141264'

Avoid tearing down assumed connection when their re-activation fails, proceed
with whatever configuration we have.

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
platform,device: merge branch 'lr/bridge-rh1141266'

Assume connections for bridges with slaves, and associated fixes for bridges.

https://bugzilla.redhat.com/show_bug.cgi?id=1141266