Add EVPN MH handlers in frrcfgd

[rakshitha-marvell]

Why I did it

SONiC's frrcfgd had no handling for EVPN Multihoming (MH) configuration. This change adds support so that EVPN-MH can be configured through ConfigDB and rendered into FRR:

• EVPN_ETHERNET_SEGMENT – per-interface Ethernet Segment configuration (Type-0 operator-configured ESI and Type-3 MAC-based ESI, with DF preference).
• EVPN_MH_GLOBAL – global EVPN-MH timers (startup-delay, mac-holdtime, neigh-holdtime).

Work item tracking

• Microsoft ADO (number only):

How I did it

• Registered EVPN_ETHERNET_SEGMENT (handled via mgmtd) and EVPN_MH_GLOBAL (handled via zebra) in the daemon table lists and the common BGP table handler.
• Added evpn_mh_global_key_map so each global timer field is added/removed (no-prefixed) individually.
• Added an EVPN_ETHERNET_SEGMENT handler that clears the interface's ES config and re-applies the full ConfigDB row:
  Type-0: applies the explicit ESI via evpn mh es-id .
  Type-3: derives es-id (falling back to the interface port number) and es-sys-mac (falling back to the PORTCHANNEL system_mac), then applies them.
• Applies es-df-pref when set to a non-default value.

How to verify it

On a device, configure an Ethernet Segment and global MH timers in ConfigDB and confirm the corresponding evpn mh ... commands appear in the FRR running config (vtysh -c 'show running-config').

Which release branch to backport (provide reason below if selected)

• 202305
• 202311
• 202405
• 202411
• 202505
• 202511
• 202605

Tested branch (Please provide the tested image version)

Description for the changelog

Link to config_db schema for YANG module changes

A picture of a cute animal (not mandatory but encouraged)

[mssonicbld]

/azp run Azure.sonic-buildimage

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[lguohan]

no unit test?

[securely1g]

Thanks for the update — overall this looks good and CI is green ✅

One request before merge: could you please add (or point to) unit tests for the new EVPN-MH handling paths in frrcfgd?

Suggested minimum coverage:

1. EVPN_MH_GLOBAL key mapping render/remove (startup_delay, mac_holdtime, neigh_holdtime)
2. EVPN_ETHERNET_SEGMENT Type-0 path (explicit esi)
3. Type-3 path with fallback behavior (es_id derivation + es_sys_mac from PORTCHANNEL system_mac)
4. delete/update behavior to confirm no evpn mh ... cleanup is applied correctly

This would make the change safer against regressions since the logic is config-branch heavy.