BGP: parse and prefer nexthop carried in MP_REACH_NLRI

[taspelund]

When MP-BGP is negotiated (even just for IPv4 Unicast), NLRI are carried in the MP_REACH_NLRI path attribute.
MP_REACH_NLRI has its own nexthop field (whose semantics are defined per afi/safi) which is separate from the NEXT_HOP path attribute.

When all NLRI carried in an update are contained within an MP_REACH_NLRI attribute, the NEXT_HOP field is optional/discouraged per RFC 4760:

The next hop information carried in the MP_REACH_NLRI path attribute
defines the Network Layer address of the router that SHOULD be used
as the next hop to the destinations listed in the MP_NLRI attribute
in the UPDATE message.
[..]

An UPDATE message that carries no NLRI, other than the one encoded in
the MP_REACH_NLRI attribute, SHOULD NOT carry the NEXT_HOP attribute.
If such a message contains the NEXT_HOP attribute, the BGP speaker
that receives the message SHOULD ignore this attribute.

I've experienced/fixed a similar issue in FRR where NEXT_HOP was implicitly used anytime it was present, even for MP-BGP NLRI that had their own nexthop encoded in the MP_REACH_NLRI attr. In that scenario, a third party BGP speaker was using its Router-ID as the NEXT_HOP for EVPN routes, while the MP_REACH_NLRI nexthop aligned to a different loopback IP. This caused the EVPN routes to be installed via the wrong nexthop.

It's probably unlikely that we'll hit this exact scenario with maghemite, but it would be good to address this proactively.