topotests: bgp_peer_type_multipath, fix test checks 1 active nexthop

The step8 fails to see in ZEBRA RIB 2 nexthop entries for the
'203.0.113.8/30' prefix.

BGP receives 2 eBGP paths.
> # show bgp ipv4
> [..]
> *= 203.0.113.8/30   198.51.100.10                          0 64503 i
> *>                  10.0.3.2                               0 64502 i

Observed output:

> # show ip route
> [..]
> B>* 203.0.113.8/30 [20/0] via 10.0.3.2, r1-eth1, weight 1, 00:22:49

Expected result:

> # show ip route
> [..]
> B>* 203.0.113.8/30 [20/0] via 10.0.3.2, r1-eth1, weight 1, 00:00:21
>  *                       via 198.51.100.10 inactive, weight 1, 00:00:21

This test demonstrates that BGP does not allow route recursivity for
those prefixes, and ZEBRA has to only use the one with 10.0.3.2 nexthop
(which is connected).

Actually, because BGP nexthop groups is configured by default, the
nexthop '198.51.100.10' is passed to ZEBRA, but ZEBRA will consider this
nexthop as inactive, because the address does not match any connected
interfaces: with ot without nexthop groups, only one nexthop is active.

This commit proposes to only check that only one nexthop is active, and
will not count the total number of nexthops.

Signed-off-by: Philippe Guibert <[email protected]>

tests/topotests/bgp_peer_type_multipath_relax/r1/prefix3-ip-route.json

@@ -4,18 +4,12 @@
       "prefix":"203.0.113.8\/30",
       "protocol":"bgp",
       "installed":true,
-      "internalNextHopNum":2,
       "internalNextHopActiveNum":1,
       "nexthops":[
         {
           "fib":true,
           "ip":"10.0.3.2",
           "active":true
-        },
-        {
-          "fib":null,
-          "ip":"198.51.100.10",
-          "active":null
         }
       ]
     }