Fix test_add_rack flakiness by waiting for BGP convergence before DB comparison

[StormLiangMS]

Description

\ est_add_rack\ was failing ~1% of PR and baseline runs with:
\
AssertionError: DB compare failed after adding T0 via generic patch updater
\\

Root Cause

In \generic_patch_add_t0(), the DB comparison (config-db, app-db, state-db) ran before BGP sessions established. After applying a JSON patch to add T0 config (BGP_NEIGHBOR, INTERFACE, PORT, etc.), BGP peers need time to converge and populate app-db route entries. The DB comparison would repeatedly fail its 5-minute retry window because app-db routes hadn't settled.

The BGP session check was placed after the DB comparison and used a bare \�ssert\ with no retry — so it never had a chance to gate the comparison.

Evidence (Kusto, last 30 days on master baseline+PR)

• 23 failures, ~90% with \DB compare failed after adding T0 via generic patch updater\
• Failures span random unrelated PRs (sonic-buildimage, sonic-mgmt) confirming it is flaky, not a regression
• Fail rate: ~0.6-1.0% on PRTest, ~0.6-2.1% on BaselineTest

Changes

• **\ ests/common/configlet/utils.py**: Add \is_bgp_session_established()\ helper that returns \True/False\ (compatible with \wait_until\ retry), with logging
• **\ ests/configlet/util/generic_patch.py**: Move BGP convergence check before DB comparison in \generic_patch_add_t0(), using \wait_until\ retry (up to 5 min). This ensures app-db routes are populated before comparing against baseline.

Before (broken ordering)

\
Apply patch → 60s pause → DB comparison (5min retry) ❌ → BGP check (no retry) ❌
\\

After (fixed ordering)

\
Apply patch → 60s pause → Wait BGP Established (5min retry) ✅ → DB comparison (5min retry) ✅
\\

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[StormLiangMS]

hi @xincunli-sonic @vaibhavhd could you help to review? This is to improve the flakyness of this case.

[StormLiangMS]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[ZhaohuiS]

@StormLiangMS the format of the description is not good enough, you can ask your agency to use this .github/PULL_REQUEST_TEMPLATE.md to generate PR.

[mssonicbld]

Cherry-pick PR to 202511: #22938

[weiguo-nvidia]

Hi @StormLiangMS ,

This PR unconditionally checks both IPv4 and IPv6 BGP sessions in generic_patch_add_t0():

assert wait_until(DB_COMP_WAIT_TIME, 20, 0, is_bgp_session_established,
                  duthost, tor_data["ip"]["remote"]), \
    "BGP IPv4 session for {} not established before DB comparison".format(tor_data["ip"]["remote"])
assert wait_until(DB_COMP_WAIT_TIME, 20, 0, is_bgp_session_established,
                  duthost, tor_data["ipv6"]["remote"].lower()), \
    "BGP IPv6 session for {} not established before DB comparison".format(tor_data["ipv6"]["remote"].lower())

On IPv6-only topologies (e.g. t1-isolated-v6-d56u1-lag), tor_data["ip"]["remote"] is an empty string because there is no IPv4 BGP neighbor. This causes is_bgp_session_established(duthost, "") to fail for the entire 5-minute retry window, resulting in:

AssertionError: BGP IPv4 session for  not established before DB comparison

I submit PR #23241 to fix the issue