Confirm Batfish BGP-MED-in-main-RIB-metric doesn't affect SR-OS route selection (low priority)

[dhalperi]

Low priority / tracking. Confirm Batfish's BGP-MED-in-main-RIB-metric vs SR-OS
doesn't affect route selection

The SR-OS main route-table does not carry the BGP MED — its only metric is the
IGP cost to resolve the BGP next-hop (0 for a directly-connected eBGP peer).
The MED lives in the bgp rib attr-set. Batfish, however, carries the BGP MED
into the main-RIB route metric, so the two main-RIB metrics measure different
quantities for BGP routes. The SrosValidator therefore skips the main-RIB
metric comparison for BGP routes and validates the MED on the BGP RIB instead
(where both sides carry it).

Open question (deferred, low priority): does Batfish's choice to put the MED in
the main-RIB metric ever affect SR-OS main-RIB route selection (e.g. tie-break
between two BGP routes to the same prefix), vs. being a benign metric-field
difference? If it can flip a selection outcome it's a modeling bug; if not, the
validator's skip is purely cosmetic and fine. Needs tracing where Batfish uses a
BGP route's main-RIB metric in selection. No lab currently exercises competing
BGP routes where MED would tie-break in the main RIB.