Let's shortcut the test by consistently checking whether num_patterns
is positive before matching.

It's more about having a consistent form of the "if" checks, than
anything else.

Signed-off-by: Wen Liang <liangwen12year@gmail.com>

https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/792

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

https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/790

When adding an IPv4 address, kernel automatically adds a local route.
This is done by fib_add_ifaddr(). Note that if the address is
IFA_F_SECONDARY, then the "src" is the primary address. That means, with

  nmcli connection add con-name t type ethernet ifname t autoconnect no \
     ipv4.method manual ipv6.method disabled \
     ipv4.addresses '192.168.77.10/24, 192.168.77.11/24'

we get two routes:

  "local 192.168.77.10 dev t table local proto kernel scope host src 192.168.77.10"
  "local 192.168.77.11 dev t table local proto kernel scope host src 192.168.77.10"

Our code would only generate instead:

  "local 192.168.77.10 dev t table local proto kernel scope host src 192.168.77.10"
  "local 192.168.77.11 dev t table local proto kernel scope host src 192.168.77.11"

Afterwards, this artificial route will be leaked:

    #!/bin/bash

    set -vx

    nmcli connection delete t || :
    ip link delete t || :

    ip link add name t type veth peer t-veth

    nmcli connection add con-name t type ethernet ifname t autoconnect no ipv4.method manual ipv4.addresses '192.168.77.10/24, 192.168.77.11/24' ipv6.method disabled

    nmcli connection up t

    ip route show table all dev t | grep --color '^\|192.168.77.11'

    sleep 1

    nmcli device modify t -ipv4.addresses 192.168.77.11/24

    ip route show table all dev t | grep --color '^\|192.168.77.11'

    ip route show table all dev t | grep -q 192.168.77.11 && echo "the local route 192.168.77.11 is still there, because NM adds a local route with wrong pref-src"

It will also be leaked because in the example above ipv4.route-table is
unset, so we are not in full route sync mode and the local table is not
synced.

This was introduced by commit 3e5fc04df320 ('core: add dependent local
routes configured by kernel'), but it's unclear to me why we really need
this. Drop it again and effectively revert commit 3e5fc04df320 ('core:
add dependent local routes configured by kernel').

I think this "solution" is still bad. We need to improve our route sync
approach with L3Cfg rework. For now, it's probably good enough.

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

This effectively reverts commit cd89026c5f4f ('core: add dependent
multicast route configured by kernel for IPv6').

It's not clear to me why this was done or why it would be correct.

True, kernel automatically adds multicast route like

  multicast ff00::/8 dev $IFACE table local proto kernel metric 256 pref medium

But NetworkManager ignores all multicast routes for now. So the dependent
routes cannot contain multicast routes as they are not handled. Also,
the code added a unicast route, so I don't understand why the comment
is talking about multicast.

This seems just wrong. Drop it.

When we deactivate a device, we flush all IP addresses and
routes. Thus, have yet another sync mode for that. It will sync more
than "ALL".