platform: always reconfigure IP routes even if removed externally

NML3Cfg is stateful, that means it remembers which address/route it
configured earlier. That is important because the API users of NML3Cfg
only say what the want to configure now, and NML3Cfg needs to remove
addresses/routes that it configured earlier but are no longer to be
present. Also, NetworkManager wants to allow the user to add
addresses/routes externally with `ip addr|route add` and NetworkManager
not removing it. This is a common use case for dispatcher scripts, but
in general, we want to allow other components to add addresses/routes.

We try something similar with the removal of routes/addresses managed by
NetworkManager. When NetworkManager adds a route/address, which later
disappears, then we assume that the user intentionally removed the
address/route and take the hint to not re-add it.

However, it doesn't work. It is problematic for two reasons:

- kernel can automatically remove routes. For example, deleting an IPv4
  address that is the prefsrc of a route, will cause kernel to delete
  that route. Sure, we may be unable to re-configure the route at this
  moment, but we shouldn't remember indefinitely that the route is
  supposed to be absent. Rather, we should re-add it when possible.

- kernel is a pain with validating consistencies of routes. For example,
  when a route has a nexthop gateway, then the gateway must be onlink
  (directly reachable), or kernel refuses to add it with "Nexthop has
  invalid gateway". Of course, when removing the onlink route kernel is
  fine leaving the gateway route behind, which it would otherwise refuse
  to add.
  Anyway. Such interdependencies for when kernel rejects adding a route
  with "Nexthop has invalid gateway" are non-trivial. We try to work
  around that by always adding the necessary onlink routes. See
  nm_l3_config_data_add_dependent_onlink_routes(). But if the user
  externally removed the dependent onlink route, and NetworkManager
  remembers to not re-adding it, then the efforts from
  nm_l3_config_data_add_dependent_onlink_routes() are ignored. This
  causes ripple effects and NetworkManager will also be unable to add the
  nexthop route.

Trying to preserve absence of routes that NetworkManager would like to
configure is not tenable. Don't do it anymore. There was anyway no
guarantee that on the next update NetworkManager wouldn't try to re-add
the route in question. For example, if the route came from DHCP, and the
lease temporarily went away and came back, then NetworkManager probably
would have (correctly) forgotten that the user wished that the route be
absent. This did not work reliably and it just causes problems.

src/core/nm-l3cfg.c

@@ -1086,16 +1086,32 @@ _obj_states_sync_filter(NML3Cfg *self, const NMPObject *obj, NML3CfgCommitType c
         return TRUE;
     }
 
-    if (obj_state->os_temporary_not_available_timestamp_msec > 0) {
-        /* we currently try to configure this address (but failed earlier).
-         * Definitely retry. */
-        return TRUE;
-    }
-
-    if (!obj_state->os_plobj && commit_type != NM_L3_CFG_COMMIT_TYPE_REAPPLY
-        && !nmp_object_get_force_commit(obj))
-        return FALSE;
-
+    /* One goal would be that we don't forcefully re-add routes which were
+     * externally removed (e.g. by the user via `ip route del`).
+     *
+     * However,
+     *
+     *  - some routes get automatically deleted by kernel (for example,
+     *  when we have an IPv4 route with RTA_PREFSRC set and the referenced
+     *  IPv4 address gets removed). The absence of such a route does not
+     *  mean that the user doesn't want the route there. It means, kernel
+     *  removed it because of some consistency check, but we want it back.
+     *  - a route with a non-zero gateway requires that the gateway is
+     *  directly reachable via an onlink route. The rules for this are
+     *  complex, but kernel will reject adding a route which has such a
+     *  gateway. If the user manually removed the needed onlink route, the
+     *  gateway route cannot be added in kernel ("Nexthop has invalid
+     *  gateway"). To handle that is a nightmare, so we always ensure that
+     *  the onlink route is there.
+     *  - a route with RTA_PREFSRC requires that such an address is
+     *  configured otherwise kernel rejects adding the route with "Invalid
+     *  prefsrc address"/"Invalid source address".  Removing an address can
+     *  thus prevent adding the route, which is a problem for us.
+     *
+     * So the goal is not tenable and causes problems. NetworkManager will
+     * try hard to re-add routes and address that it thinks should be
+     * present. If you externally remove them, then you are starting a
+     * fight where NetworkManager tries to re-add them on every commit. */
     return TRUE;
 }