nm-setting: implement direct_enum as GObject property of type int

Summary

Rework _nm_setting_property_define_direct_enum so we can easily define enum properties that allows backwards compatibility.

Purpose

If we define a NetworkManager property implemented as an enum in the GObject property there are API compatibility problems with clients using old libnm. The problem arises when we add a new value to the enum and it's sent from the daemon to the client with old libnm, then the client gets a glib assertion because it doesn't recognize that value as valid.

The solution is to implement it as integer in the GObject, and setting the min-max range to G_MININT - G_MAXINT, so glib won't assert against any new value. To validate the values received in the daemon, it should be done in NMSettingXXX:verify because clients normally don't call it as they have to accept whatever comes from the daemon.

But it is unfortunate that this validation in 'verify' has to be done manually. Rework _nm_setting_property_define_direct_enum so this validation is done for any property defined as NM_VALUE_TYPE_ENUM. Also, add _nm_setting_property_define_direct_real_enum for those properties that need to use real enums in the GObject, either because they were already defined as such or because any other reason. _nm_setting_property_define_direct_real_enum is supposed to be used very rarely for new properties, or never.

Note: I have converted connection.autoconnect-slaves to real_enum, but NOT connection.autoconnect-ports. We are still on time to introduce autoconnect-ports as enum (not real_enum) in 1.46.

Checklist

Please read https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/main/CONTRIBUTING.md before opening the merge request. In particular, check that:

• the subject for all commits is concise and explicative
• the message for all commits explains the reason for the change
• the source is properly formatted
• any relevant documentation is up to date
• you have added unit tests if applicable