Demoting IPv4 link-local services in service list sorting

I am trying to teach ConnMan to give IPv4 link-local services lower
priority than READY/ONLINE services using another ipconfig method (e.g.
DHCP). This seems like a useful heuristic, given that link-local
services are not suitable for configuring the default route.

As far as I can see, two changes would be required:

1. Adding a condition to service_compare(), something like this:

    /* Prefer configured IPv4 address over auto/link-local IP.
     *
     * This just checks for CONNMAN_IPCONFIG_METHOD_AUTO, but other
     * checks could be done.
     */
    bool a_is_link_local = is_ipv4ll(service_a);
    bool b_is_link_local = is_ipv4ll(service_b);
    if (a_connected && !a_is_link_local && b_is_link_local)
        return -1;
    if (a_is_link_local && b_connected && !b_is_link_local)
        return 1;

2. Triggering re-sorting when IP/ipconfig method of a service changes

Currently formerly link-local services are not actually promoted when
DHCP becomes active. This is likely because a service that transitions
from IPv4LL to DHCP just remains in READY state, and no re-sorting
occurs.

To address this, ConnMan would need to trigger re-sorting of the service
list when a service's ipconfig method or IP address changes. I am
currently looking into triggering sorting from service_ip_bound() or
address_updated() and this works in a basic test by just adding:

        SERVICE_LIST_SORT();
        __connman_gateway_update();


I would be grateful for any feedback on the below:

- Is address_updated() an appropriate place to hook into, are there any
  risks/downsides I am overlooking?
- Is there a more natural existing hook to trigger sorting from, or
  should a new one be added?
- Is there any reason not to demote link-local services in the way I
  described?


Context for this change

Our kiosk system built with ConnMan typically uses two simultaneous
Ethernet connections, one to an input device using a link-local address,
one to some network providing Internet access. In most cases ConnMan
reliably uses the Internet-bound network as the default service, but if
the network is slow to respond to DHCP requests for some reason, both
Ethernet services end up with link-local addresses initially. In this
case, ConnMan may choose the local-only connection as default service
and stick with that choice even when the other service receives a good
IP and gateway via DHCP later. Continuous online checks are not
currently a good fit for us and should not be required as it is known a
priori that link-local services are not useful as default services.

Thanks,
Johannes