ip: preserve connected routes during protocol replay

[hcaldicott]

During control-plane replay, a routing daemon can briefly advertise a
connected prefix before it has learned the interface address, then
withdraw it again once it reconciles. route4_add() replaces the
address-owned connected route with the protocol route, so the later
withdrawal removes the only route to the prefix while the address stays
configured — the connected network is unreachable until the address is
removed and re-added.

This change treats address-owned connected routes as authoritative:
protocol adds for such prefixes are accepted as a silent no-op, and API
deletes of internal-origin routes are refused the same way. Deletions now
resolve their nexthop with an exact-prefix lookup first, so the nexthop
type of a covering route is never used to delete a more specific prefix;
the previous longest-prefix lookup remains as the fallback when no exact
entry exists. Same handling for both address families.

Found while integrating FRR restart handling for EVPN multihoming (#698),
but the race only needs a routing daemon replaying routes over a
configured address.

Testing

• New smoke test connected_route_ownership_test.sh replays the
  add/withdraw cycle over configured IPv4 and IPv6 addresses and asserts
  the connected routes survive with their link origin.
• Without the fix (test-only applied to main): the test fails at the
  first assertion — after add/withdraw, 172.16.0.0/24 is gone from the
  RIB entirely.
• With the fix: the new test passes, the full unit suite passes, and
  ip_loadbalance_test.sh confirms ordinary route add/del and ECMP
  behaviour is unchanged (AlmaLinux 9 container, arm64).

Related: #698

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0)

Great, no issues found!

Qodo reviewed your code and found no material issues that require review

Tip of the day

💡 Did you know, you can route each action level your way: inline, summary, both, or drop

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[rjarry]

Hey Harrison,

Your check is a bit loose. See how to make it more robust below.

Also could you remove any mention that you were assisted by AI? It does not bring much value and we prefer to keep the git history leaner.

Thanks!

[hcaldicott]

Hey Harrison,

Your check is a bit loose. See how to make it more robust below.

Also could you remove any mention that you were assisted by AI? It does not bring much value and we prefer to keep the git history leaner.

Thanks!

Good pickups - I will address these and re-run my lab tests!

[hcaldicott]

I have updated the PR. I am now rebuilding our physical lab on this to re-test the corrected behaviour. Converting back to a draft until my testing is completed.