Initial IP configuration can happen during ACTIVATED state if both
v4 and v6 are enabled, but one takes longer than the other. Thus
various checks throughout the code for IP_CONFIG were incorrect
since they depended on IP configuration only happening during the
IP_CONFIG state. Fix that by using a separate state for IP config
and using that state for various checks instead of the overall
device state.
It was somewhat pointless since the IP config is always known when
stage4 gets scheduled, so why not just pass the config to stage5
immediately? Also helps consolidate the v4/v6 failure handling
logic and makes the operational flow clearer where both v4 and
v6 are active and proceeding in parallel.
These days more and more devices are showing up that support a
number of different access technology families in the same hardware,
like Qualcomm Gobi (CDMA and GSM), Pantech UM190 (CDMA and GSM),
Pantech UML290 (CDMA and LTE), LG VL600 (CDMA and LTE), Sierra
320U (GSM and LTE), etc. The previous scheme of having device
classes based on access technology family simply cannot handle
this hardware and attempting to add LTE to both the CDMA and GSM
device classes would result in a bunch of code duplication that
we don't want. There's a better way...
Instead, combine both CDMA and GSM device classes into a generic
"Modem" device class that provides capabilities indicating what
access technology families a modem supports, and what families
it supports immediately without a firmware reload. (Gobi devices
for example require a firmware reload before they can switch
between GSM and CDMA). This provides the necessary flexibility
to the client and allows us to keep the API stable when the
same consolidation change is made in ModemManager.
The current code doesn't yet allow multi-mode operation internally,
but the API is now what we want it to be and won't need to be
changed.
deactivate_quickly is misnamed these days; it was originally used
for quickly tearing down a device for sleep and such. But these
days it's used for the bulk of device deactivation. Only the wifi
class used the actual deactivate method. So combine the two and
make device implementations less complicated.
Given connection details, complete the connection as well as possible
using the given specific object and device, add it to system
settings, and activate it all in one method.
Instead of a bizare mechanism of signals back to the manager
object that used to be required because of the user/system settings
split, let each place that needs secrets request those secrets
itself. This flattens the secrets request process a ton and
the code flow significantly.
Previously the get secrets flow was something like this:
nm_act_request_get_secrets ()
nm_secrets_provider_interface_get_secrets ()
emits manager-get-secrets signal
provider_get_secerts ()
system_get_secrets ()
system_get_secrets_idle_cb ()
nm_sysconfig_connection_get_secrets ()
system_get_secrets_reply_cb ()
nm_secrets_provider_interface_get_secrets_result ()
signal failure or success
now instead we do something like this:
nm_agent_manager_get_secrets ()
nm_agent_manager_get_secrets ()
request_start_secrets ()
nm_sysconfig_connection_get_secrets ()
return failure or success to callback
As long as at least one IP config method completes, and as long as
methods that the user required to complete do complete, allow the
connection to complete.
After the DUN branch merge (I think?) a number of NM_IS_MODEM
calls were left around which now always return FALSE since
NMDeviceCdma and NMDeviceGsm aren't subclasses of NMModem anymore.
But we still need generic "is this a modem subclass" checks in
a few places, so add a modem base class that both the GSM and
CDMA device classes inherit from and use that.
Plus, we want to consolidate a ton of the common code in
nm-device-gsm.c and nm-device-cdma.c into the base class in the
future anyway.
