$ find * -type f |xargs perl contrib/scripts/spdx.pl
  $ git rm contrib/scripts/spdx.pl

Completely refactor the team/JSON handling in libnm's NMSettingTeam and
NMSettingTeamPort.

- team handling was added as rh#1398925. The goal is to have a more
  convenient way to set properties than constructing JSON. This requires
  libnm to implement the hard task of parsing JSON (and exposing well-understood
  properties) and generating JSON (based on these "artificial" properties).
  But not only libnm. In particular nmcli and the D-Bus API must make this
  "simpler" API accessible.

- since NMSettingTeam and NMSettingTeamPort are conceptually the same,
  add "libnm-core/nm-team-utils.h" and NMTeamSetting that tries to
  handle the similar code side-by-sdie.
  The setting classes now just delegate for everything to NMTeamSetting.

- Previously, there was a very fuzzy understanding of the provided
  JSON config. Tighten that up, when setting a JSON config it
  regenerates/parses all other properties and tries to make the
  best of it. When modifying any abstraction property, the entire
  JSON config gets regenerated. In particular, don't try to merge
  existing JSON config with the new fields. If the user uses the
  abstraction API, then the entire JSON gets replaced.

  For example note that nm_setting_team_add_link_watcher() would not
  be reflected in the JSON config (a bug). That only accidentally worked
  because client would serializing the changed link watcher to
  GVariant/D-Bus, then NetworkManager would set it via g_object_set(),
  which would renerate the JSON, and finally persist it to disk. But
  as far as libnm is concerned, nm_setting_team_add_link_watcher() would
  bring the settings instance in an inconsistent state where JSON and
  the link watcher property disagree. Setting any property must
  immediately update both the JSON and the abstraction API.

- when constucting a team setting from D-Bus, we would previously parse
  both "config" and abstraction properties. That is wrong. Since our
  settings plugins only support JSON, all information must be present
  in the JSON config anyway. So, when "config" is present, only the JSON
  must be parsed. In the best case, the other information is redudant and
  contributes nothing. In the worse case, they information differs
  (which might happen if the client version differs from the server
  version). As the settings plugin only supports JSON, it's wrong to
  consider redundant, differing information from D-Bus.

- we now only convert string to JSON or back when needed. Previously,
  setting a property resulted in parsing several JSON multiple times
  (per property). All operations should now scale well and be reasonably
  efficient.

- also the property-changed signals are now handled correctly. Since
  NMTeamSetting knows the current state of all attributes, it can emit
  the exact property changed signals for what changed.

- we no longer use libjansson to generate the JSON. JSON is supposed
  to be a machine readable exchange format, hence a major goal is
  to be easily handled by applications. While parsing JSON is not so
  trivial, writing a well-known set of values to JSON is.
  The advantage is that when you build libnm without libjansson support,
  then we still can convert the artificial properties to JSON.

- Requiring libjansson in libnm is a burden, because most of the time
  it is not needed (as most users don't create team configurations). With
  this change we only require it to parse the team settings (no longer to
  write them). It should be reasonably simple to use a more minimalistic
  JSON parser that is sufficient for us, so that we can get rid of the
  libjansson dependency (for libnm). This also avoids the pain that we have
  due to the symbol collision of libjansson and libjson-glib.

https://bugzilla.redhat.com/show_bug.cgi?id=1691619

NM_SETTING_NAME is a special property that only has relevance
to libnm. It is inherited by all NMSetting instances. It is
read-only, and it has no corresponding value on D-Bus or nmcli.

Skip it during generate-setting-docs.py.

This also drops it from `man nm-settings`, where it doesn't belong.

get_prop_type() cannot ever return "gchar", because it only returns
values from "dbus_type_name_map" or for enums it has the form

  "%s (%s)" % (pspec.value_type.name, prop_type)

Another reason why get_prop_type() cannot ever return a "char" type,
is because of what get_prop_type() does. get_prop_type() only returns
types based on the D-Bus type of the property, and on D-Bus there is
no fundamental type for a one-character string. There is either a
(UTF-8 encoded) string, or integer values of varying sizes. But in
terms of unicode, a 'char' type makes little sense on D-Bus. And neither
does it for get_prop_type().

generate-settings-docs.py script uses the `LD_LIBRARY_PATH` to
prepend directories to the library search path, which is useful to
load a just built libnm shared library, when generating the
`nm-settings-docs.xml` and `nm-property-docs.xml` files.

However, this is a problem for meson, which is not able to set
environment variables when executing the script.

This patch adds a new optional parameter, `-l` or `--lib-path` that
can be used to pass different paths to be prepended without using
the `LD_LIBRARY_PATH` environment, which can still be used.

[thaller@redhat.com: fix script to handle None lib_path argument]

https://mail.gnome.org/archives/networkmanager-list/2017-December/msg00044.html

Will be useful for tc qdiscs.

Also mark them for translation.