The errors were documented as org.freedesktop.NetworkManager.VPN.Error.*,
but the actual values were org.freedesktop.NetworkManager.VPN.Plugin.*

Also update the errors documentation.

The ConnectInteractive() -> Connect() fallback code doesn't work, because
_connect_internal() changes the state to NM_VPN_SERVICE_STATE_STARTING before
checking if it can implement ConnectInteractive(), and then when the Connect()
call comes in, the VPN is not in STOPPED or INIT, so it returns an error.

The commit moves setting state to STARTING after the ConnectInteractive() check
availability, in the plugin. We introduce new plugin error and set it when the
the plugin does not implement ConnectInteractive(). NetworkManager uses this
error for ConnectInteractive() -> Connect() fallback.

https://bugzilla.gnome.org/show_bug.cgi?id=708255

Add new API to allow passing both IPv4 and IPv6 configuration
information from VPN plugins to the backend.

Now instead of a single Ip4Config, a plugin has Config, Ip4Config, and
Ip6Config. "Config" contains information which is neither IPv4 nor
IPv6 specific, and also indicates which of Ip4Config and Ip6Config are
present. Ip4Config now only contains the IPv4-specific bits of
configuration.

There is backward compatibility in both directions: if the daemon is
new and the VPN plugin is old, then NM will notice that the plugin
emitted the Ip4Config signal without having emitted the Config signal
first, and so will assume that it is IPv4-only, and that the generic
bits of configuration have been included with the Ip4Config. If the
daemon is old and the plugin is new, then NMVPNPlugin will copy the
values from the generic config into the IPv4 config as well. (In fact,
NMVPNPlugin *always* does this, because it's harmless, and it's easier
than actually checking the daemon version.)

Currently the VPN is still configured all-at-once, after both IPv4 and
IPv6 information has been received, but the APIs allow for the
possibility of configuring them one at a time in the future.

Even if a VPN is only tunneling IPv4, you might still be connected to
the tunnel endpoint via IPv6. Allow
NM_VPN_PLUGIN_IP4_CONFIG_EXT_GATEWAY to be either an IPv4 or an IPv6
address, and set up an appropriate static route either way.

Minor fixes and cleanups by dcbw.

	* include/NetworkManager.h
	  introspection/nm-device.xml
	  include/NetworkManagerVPN.h
		- Add a few more state reasons for the device deactivated state

	* src/nm-device-interface.c
	  src/nm-device-interface.h
		- (nm_device_interface_deactivate): add a 'reason' argument

	* src/nm-device.c
	  src/nm-device.h
		- (nm_device_deactivate, nm_device_take_down): add a 'reason' argument
		- (nm_device_state_changed): pass the state change reason to
			nm_device_take_down()
		- (nm_device_set_managed): take a 'reason' argument, and pass it along
			to the state change function

	* src/nm-manager.c
	  src/nm-manager.h
		- (remove_one_device, handle_unmanaged_devices, sync_devices,
		   impl_manager_sleep): pass a reason code to nm_device_set_managed()
		- (nm_manager_deactivate_connection): add a 'reason' argument and pass
			something reasonable along to VPN deactivation

	* src/vpn-manager/nm-vpn-manager.c
	  src/vpn-manager/nm-vpn-manager.h
		- (nm_vpn_manager_deactivate_connection): add a 'reason' argument and
			pass that along to nm_vpn_connection_disconnect()



git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@4174 4912f4e0-d625-0410-9fb7-b9a5a253dbdc