No way to set dhcp-send-hostname globally

I'm re-opening an issue from the old bugzilla, which is still present in NM.

Here's a relevant reply from @thaller:

The only problem is that "ipv4.dhcp-send-hostname" cannot be set by default. And the reason that is hard to extend is because the property is a boolean value.

Properties that allow for their default value to be overwritten all require that they have a special value which allows for the fallback to the default value. The boolean property ipv4.dhcp-send-hostname doesn't have a value to allow for such a default value. The goal of this rule is that the per-profile value always takes precedence.

there are some solutions, all ugly:

a) make an exception for ipv4.dhcp-send-hostname. The per-profile value YES would mean: "lookup globally configured value, and if unspecified, use YES". That is ugly, because now the global default takes precedence.

b) deprecate ipv4.dhcp-send-hostname and add a new property that can encode 3 values. I think this is the way to go.

I think, ipv4.dhcp-send-hostname should be deprecated and replaced by new NM_DHCP_HOSTNAME_FLAG_*. Patch welcome :)

It was discussed here: !198 (comment 328579) but not done (yet).

For example, there could be two new flags:

• NM_DHCP_HOSTNAME_FLAG_SEND_HOSTNAME
• NM_DHCP_HOSTNAME_FLAG_NO_SEND_HOSTNAME

if any of these two flags is set, then ipv4.dhcp-send-hostname gets ignored. Also, nm_connection_normalize() should be extended to enforce that conflicting flags agree.

I don't have a good understanding of the code, so I probably have some misconceptions. Looking at the documentation for connection properties, I get the impression that the default value for a property is always static. However, I don't see why we couldn't have the default value for the ipv4.dhcp-send-hostname connection property be dependent on the value of a global ipv4.dhcp-send-hostname. In a connection profile setting ipv4.dhcp-send-hostname= or having no ipv4.dhcp-send-hostname should mean to use the default value.