NM already includes <linux/if.h> in some places, f.e. nm-netlink-monitor and
we can't mix usage of the two. Stick to using <linux/if.h> as it provides
additional flag definitions such as operational link state and link mode.

Signed-off-by: Thomas Graf <tgraf@redhat.com>

The core problem was the nm_connection_need_secrets() call in
nm-agent-manager.c's get_start() function; for VPN settings this
always returns TRUE.  Thus if a VPN connection had only system
secrets, when the agent manager checked if additional secrets
were required, they would be, and agents would be asked for
secrets they didn't have and couldn't provide.  Thus the
connection would fail.  nm_connection_need_secrets() simply
can't know if VPN secrets are really required because it
doesn't know anything about the internal VPN private data;
only the plugin itself can tell us if secrets are required.

If the system secrets are sufficient we shouldn't be asking any
agents for secrets at all.  So implement a three-step secrets
path for VPN connections.  First we retrieve existing system
secrets, and ask the plugin if these are sufficient.  Second we
request both existing system secrets and existing agent secrets
and again ask the plugin if these are sufficient.  If both those
fail, we ask agents for new secrets.

Make it clearer what's going on instead of using flags here and there
and numbers elsewhere.

Not used yet, but will be when device deactivating state gets
used.  Should be 100% backwards compatible with users that don't
know about it for now.