feat(nm): L2Only as alias of Unmanaged mode

[mattdibi]

This PR fixes the behaviour of the netIPv4StatusL2Only/netIPv6StatusL2Only parameter.

Up until now netIPvXStatusL2Only was not correctly supported in our codebase in our generic profiles. See:

kura/kura/org.eclipse.kura.nm/src/main/java/org/eclipse/kura/nm/NMDbusConnector.java

Lines 87 to 88 in ca95dd7

	private static final List<KuraIpStatus> CONFIGURATION_SUPPORTED_STATUSES = Arrays.asList(KuraIpStatus.DISABLED,
	KuraIpStatus.ENABLEDLAN, KuraIpStatus.ENABLEDWAN, KuraIpStatus.UNMANAGED);

This meant that, when configured as netIPvXStatusL2Only, Kura would quit configuration without touching the interface. See

kura/kura/org.eclipse.kura.nm/src/main/java/org/eclipse/kura/nm/NMDbusConnector.java

Lines 467 to 472 in ca95dd7

	if (!CONFIGURATION_SUPPORTED_DEVICE_TYPES.contains(deviceType)
	|| !CONFIGURATION_SUPPORTED_STATUSES.contains(ip4Status)
	|| !CONFIGURATION_SUPPORTED_STATUSES.contains(ip6Status)) {
	logger.warn("Device \"{}\" of type \"{}\" with status \"{}\"/\"{}\" currently not supported", deviceId,
	deviceType, ip4Status, ip6Status);
	return;

This behaviour technically still obtains the desired configuration (interface is up and the user is free to configure it) but is not quite correct.

This PR simply promotes netIPv4StatusL2Only to an alias of netIPv4StatusUnmanaged thus obtaining the expected behaviour.

Note: To preserve the compatibility with older Kura versions and the old-networking profiles, specifying only IPv4 as "L2Only" will suffice to set the whole interface as "Unmanaged". This is due to the fact that originally, there was no IPv6 support.

For "Unmanaged" we require users to set both IPv4 and IPv6 as "Unmanaged" otherwise we will throw an error. This is because "Unmanaged" is a property of the whole network interface not only the IPv4/6 part of the settings. The same applies for L2Only but, requiring the IPv4 and IPv6 status to be both set to L2Only would break compatibility with old snapshots.

@pierantoniomerlino I have only one doubt: currently, if the IPv6 status is UNKNOWN the method won't throw an exception. The original idea was to throw an exception when any of the statuses was UNKNOWN but, if we do with L2ONLY, we might risk breaking existing snapshots? What do you think?

You can use the introduced tests to understand what's going on.

[pierantoniomerlino]

The code looks ok to me. However, I've some doubts about the meaning of this feature. At the end, the L2Only is only another label to mean Unmanaged. So, IMO it's more clear and less confusing to the end user use the latter label instead of "L2Only" and document it.
Moreover, the combinations of IPv4 and IPv6 statuses should be clearly documented to avoid confusion.

I understand that in this way the old configurations could not work anymore, but I think that with Kura 6 we can accept a breaking change.

@mattdibi @MMaiero what do you think?

[pierantoniomerlino]

I have only one doubt: currently, if the IPv6 status is UNKNOWN the method won't throw an exception. The original idea was to throw an exception when any of the statuses was UNKNOWN but, if we do with L2ONLY, we might risk breaking existing snapshots? What do you think?

@mattdibi
Mhh.... UNKNOWN as a status means that something went wrong with the network interface. So, IMO is it correct to throw an exception. If one sets an IPv4 interface as L2ONLY, the IPv6 will be disabled by default, isn't it?

[mattdibi]

If one sets an IPv4 interface as L2ONLY, the IPv6 will be disabled by default, isn't it?

Nopes. Kura will just not touch the configuration it finds.

Also note that there's a little quirk with L2ONLY: it is a property of the interface and doesn't (or better "shouldn't") have any concept of layer 3 stuff.

[MMaiero]

The code looks ok to me. However, I've some doubts about the meaning of this feature. At the end, the L2Only is only another label to mean Unmanaged. So, IMO it's more clear and less confusing to the end user use the latter label instead of "L2Only" and document it. Moreover, the combinations of IPv4 and IPv6 statuses should be clearly documented to avoid confusion.

I understand that in this way the old configurations could not work anymore, but I think that with Kura 6 we can accept a breaking change.

@mattdibi @MMaiero what do you think?

I agree, I believe we should only have one entry (most likely the unmanaged one) in the UI. The backend should be able to manage the old l2 property and maybe convert it to unmanaged.
But the user at this point is not were of the difference between the two

[mattdibi]

Ok, I will revert back to the 39d7aba implementation.

This should work because, if IPv6 is missing (like it should in old specific-profiles Kura versions), we have the following bit of logic that fills it in:

kura/kura/org.eclipse.kura.nm/src/main/java/org/eclipse/kura/nm/NMDbusConnector.java

Lines 459 to 463 in c0feb0b

	if (!ip6OptStatus.isPresent()) {
	ip6Status = ip4Status == KuraIpStatus.UNMANAGED ? KuraIpStatus.UNMANAGED : KuraIpStatus.DISABLED;
	} else {
	ip6Status = ip6OptStatus.get();
	}

If, when IPv4 is set to L2ONLY, IPv6 is present in the snapshot it should match IPv4 (i.e. UNMANAGED) otherwise Kura will throw an exception (as per our offline discussion with @pierantoniomerlino). Does this look ok for everybody?

After this I will remove the "L2ONLY" entry from the UI.

[mattdibi]

After testing I found out that my assumption in #5663 (comment) were wrong: if IPv6 is missing from the snapshot it gets automatically DISABLED. Therefore I reverted back to the original implementation where setting the IPv4 status as L2Only will override IPv6 settings and be interpreted as UNMANAGED.

This should not break compatibility with older snapshot.