bgpd: Prevent multipathing among EVPN and non-EVPN paths

bgpd: Prevent multipathing among EVPN and non-EVPN paths

Ensure that a multipath set is fully comprised of EVPN paths (i.e.,
paths imported into the VRF from EVPN address-family) or non-EVPN
paths. This is actually a condition that existed already in the code
but was not properly enforced.

This change, as a side effect, eliminates the known trigger condition
for bad or missing RMAC programming in an EVPN deployment, described
in tickets CM-29043 and CM-31222. Routes (actually, paths) in a VRF
routing table that require VXLAN tunneling to the next hop currently
need some special handling in zebra to deal with the nexthop (neigh)
and RMAC programming, and this is implemented for the entire route
(prefix), not per-path. This can lead to the bad or missing RMAC
situation, which is now eliminated by ensuring all paths in the route
are 'similar'.

The longer-term solution in CL 5.x will be to deal with the special
programming by means of explicit communication between bgpd and zebra.
This is already implemented for EVPN-MH via CM-31398. These changes
will be extended to non-MH also and the special code in zebra removed
or refined.

Signed-off-by: Vivek Venkatraman <vivek@nvidia.com>
Acked-by:      Trey Aspelund <taspelund@nvidia.com>
Acked-by:      Anuradha Karuppiah <anuradhak@nvidia.com>
Acked-by:      Chirag Shah <chirag@nvidia.com>
Ticket: CM-29043
Testing Done:
1. Manual testing
2. precommit on both MLX and BCM platforms
3. evpn-smoke - BCM and VX

Results described in the ticket

(cherry picked from commit d2d71b042edc628cb6edae0b25d0a49aa9ad2050)