[Dependent on PR#21415] Feature/route programming time

[PriyanshTratiya]

Description of PR

Summary:
Fixes # (issue)
This PR adds test cases and supporting utilities to measure route programming time under high‑scale BGP IPv6 scenarios, building on the refactoring in PR #21335 and the high‑BGP‑flap coverage in PR #21415. It focuses on quantifying how long it takes for routes to be fully programmed after BGP/connection events (e.g., convergence, admin flaps), and verifying that the measured RP times stay within expected limits and similar to the convergence time.

Key Points:

• Introduces new tests that:
  • Trigger BGP route updates (via scale, convergence, and flap scenarios) and
  • Measure end‑to‑end route programming time from control‑plane event to data‑plane readiness.
• Adds helper logic to:
  • Capture timestamps around BGP state/route changes and data‑plane verification,
  • Collect and aggregate per‑iteration route programming statistics,
  • Expose pass/fail criteria based on configured thresholds.
• Reuses the generalized connection and flap mechanisms introduced in PR Refactoring/high bgp phase 2 #21335 and PR [Dependent on PR#21335] Feature/bgp flap high bgp phase 2 #21415 to generate realistic route programming events at scale.
• Enhances logging so that per‑iteration programming times are visible for debugging and trend analysis.
• Keeps tests parameter‑driven to allow different scales, iteration counts, and thresholds without duplicating logic.

Dependency:

• Depends on the APIs and test structure introduced in:
  • PR #21335 (refactoring/high‑bgp‑phase‑2)
  • PR #21415 (BGP flap high‑bgp phase‑2)
• This PR assumes those helpers and test flows are available and extends them with route‑programming‑time measurement.

Type of change

• Bug fix
• Testbed and Framework(new/improvement)
• New Test case
  • Skipped for non-supported platforms
• [ x ] Test case improvement

Back port request

• 202205
• 202305
• 202311
• 202405
• 202411
• 202505

Approach

What is the motivation for this PR?

After adding flexible convergence and flap coverage in PR #21335 and PR #21415, we also need quantitative visibility into route programming performance. Specifically:

• How long does it take for routes to be fully programmed after:
  • Initial BGP convergence under scale,
  • BGP admin flaps or port flaps,
  • Large‑scale route updates?
• Do these programming times remain within agreed targets across iterations and scales?
• Can we detect regressions or platform‑specific performance issues in route programming latency?

How did you do it?

• Added new route‑programming‑time test flows (in tests/bgp/test_ipv6_bgp_scale.py) that:
  • Use existing mechanisms to:
    • Establish BGP sessions and advertise a high scale of IPv6 routes.
    • Trigger events (e.g., convergence, admin flap cycles) using the refactored connection APIs.
  • Around each event, record:
    • The time when the control‑plane action is taken (e.g., admin shut/no‑shut, route announcement),
    • The time when verification confirms that routes are fully programmed and forwarding is working.
  • Compute route programming time as the delta between these timestamps.
• Implemented helper functions to:
  • Configure thresholds for acceptable route programming time,
  • Aggregate and report per‑iteration statistics,
  • Mark the test as failed if the measured times exceed configured limits.
• Reused logging and verification utilities from the refactored BGP test infrastructure so that:
  • The tests share as much code as possible with the convergence and flap tests,
  • Route programming time measurements can be correlated with existing convergence logs.

How did you verify/test it?

• Executed the new route programming time tests in the same environment used for the high‑bgp and flap tests:
  • Topology: t0-isolated-d2u510s2
  • Platform: Broadcom Arista-7060X6-64PE-B-C512S2
• Verified that:
  • Route programming times are collected and logged for each iteration,
  • Measured values are stable and within expected thresholds under high scale,
  • No unexpected failures or long‑tail outliers appear during repeated runs.

Any platform specific information?

• Verified on Broadcom Arista-7060X6-64PE-B-C512S2 (or the platform(s) you actually used).
• The test logic itself is platform‑agnostic, but measured route programming times are naturally platform and scale dependent.

Supported testbed topology if it's a new test case?

Documentation

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines will not run the associated pipelines, because the pull request was updated after the run command was issued. Review the pull request again and issue a new run command.