Rename _nm_object_handle_properties_changed(), etc, to be about
properties in general, rather than just property changes.
Interpret func==NULL in NMPropertiesInfo as meaning "use
_nm_object_demarshal_generic", and then reorder the fields so that you
can just leave that field out in the declarations when it's NULL.
Add a way to register properties that exist in D-Bus but aren't
tracked by the NMObjects, and use that for NMDevice's D-Bus Ip4Address
property, replacing the existing hack.
Also add a few other missing properties noticed along the way.
Like the *_filter_connections() functions, but for just one connection,
and now the *_filter_connections() functions call these new ones so
it's really just moving code around and not anything new.
These new functions more closely match the usage I've seen from
gnome-shell's network.js and elsewhere.
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.
