Fix failure to add an interface prefix route when route with the same prefix is already presented in the routing table.

[zlei]

Is this a replacement of D46301 ?

[jlduran]

The reported test passes successfully:

# route add -net 192.0.2.0/24 -interface vtnet0
add net 192.0.2.0: gateway vtnet0
# ifconfig epair create
epair0a
# ifconfig epair0a inet 192.0.2.1/24
# route show 192.0.2.0/24
   route to: 192.0.2.0
destination: 192.0.2.0
       mask: 255.255.255.0
        fib: 0
  interface: epair0a
      flags: <UP,DONE,PINNED>
 recvpipe  sendpipe  ssthresh  rtt,msec    mtu        weight    expire
       0         0         0         0      1500         1         0

Thank you!

[jlduran]

Sigh, it looks like this commit broke the following test:
https://ci.freebsd.org/view/Test/job/FreeBSD-main-amd64-test/lastCompletedBuild/testReport/junit/sys.net.routing.test_routing_l3/py/TestIfOps__test_change_prefix_route_inet_/
To reproduce:

# create two interfaces
if1=$(ifconfig epair create)
if2=$(ifconfig epair create)
# assign IP addresses in the same subnet
ifconfig $if1 inet 192.0.2.1/24
ifconfig $if2 inet 192.0.2.2/24
# Verify that the route points to the first interface (fails, as $if2 was added last, it points to $if2)
netstat -r4n | grep 192.0.2.0/24
# Remove the first interface
ifconfig $if1 destroy
# Verify that the route points to the second interface (it also fails, even if we remove $if2, we will have no route)
netstat -r4n | grep 192.0.2.0/24

[ae]

In D47534#1085033, @jlduran wrote:

Sigh, it looks like this commit broke the following test:

# create two interfaces
if1=$(ifconfig epair create)
if2=$(ifconfig epair create)
# assign IP addresses in the same subnet
ifconfig $if1 inet 192.0.2.1/24
ifconfig $if2 inet 192.0.2.2/24
# Verify that the route points to the first interface (fails, as $if2 was added last, it points to $if2)
netstat -r4n | grep 192.0.2.0/24

IMHO, we need to fix this behaviour. 
First PINNED route should have priority and second attempt to add the same route on $if2 should fail with EEXIST.
But then the test will fail, because after address deletion from $if1 there will not be any PINNED routes.