NML3Cfg is supposed to manage an interface (by ifindex).
As such, it later will itself implement DHCP and similar addressing
methods.
However, in various cases we get additional IP configuration from
external (e.g. from a VPN connection). To support that, let NML3Cfg
track any number of NML3ConfigData instances.
NML3ConfigData is supposed to be used as immutable, ref-counted type.
You create it once, initialize it, seal it, and pass (immutable) references
around.
In such a scheme, having ref/unref functions not operate on const pointers
is a major inconvenience.
NML3ConfigData tracks IP addresses and routes. In their current form, these
types (NMPObject) always have an ifindex and there is no sensible way to have
an NMPObject (for routes or addresses) that have a wildcard ifindex.
Honor that by also tying NML3ConfigData to an ifindex. In most cases, the
user knows the ifindex before and can create it. On the unlikely case where
the user doesn't know the ifindex, we should add a new nm_l3_config_data_clone()
function, which allows migrating the setting from one ifindex to another.
Currently NMIP4Config and NMIP6Config both track the data to be
configured, they expose properties on D-Bus, and they have logic for
capturing and applying settings to platform.
We will split that.
- NMIP4Config and NMIP6Config will expose data on D-Bus.
- NML3Cfg will have the logic for handling IP configuration.
- NML3ConfigData will track data to be configured.
NML3ConfigData mirrors NMIP4Config/NMIP6Config in many aspects. For now,
this duplicates a lot of code. More will be done later. Eventually,
NMIP4Config/NMIP6Config will drop the duplicated functionality.
