[platform_tests] Flap LPMODE-skipped transceivers after SFP reset

[LinJin23]

Description of PR

Ensure transceivers intentionally skipped by the LPMODE validation are still flapped after sfp.reset().

is_xcvr_support_lpmode() returns False for entries in LPMODE_SKIP_LIST. The reset test previously reused that result to select interfaces for recovery, so those transceivers were reset but omitted from the shutdown/startup flap. On affected Arista 7280DR3 systems with Cloud Light 7123-G37 modules, the transceiver remained in low-power mode and the interface stayed operationally down.

Type of change

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

Back port request

• 202311
• 202405
• 202411
• 202505
• 202511
• 202512
• 202605

Tracking issue/work item for backport/cherry-pick request (GitHub issue or Microsoft ADO): https://msazure.visualstudio.com/One/_workitems/edit/38573079
Failure type: day-one issue

Tested branch

• master
• 202311
• 202405
• 202411
• 202505
• 202511
• 202512
• 202605
• N/A

Test result

• master: Pre-commit Python AST and flake8 checks passed; python3 -m py_compile tests/platform_tests/api/test_sfp.py passed. Hardware validation is pending.
• 202511 failure reproduction: SONiC.20251110.42 - https://elastictest.org/scheduler/testplan/6a6e1284c4dbc22bce9ce727?testcase=platform_tests%2Fapi%2Ftest_sfp.py&type=console. Post-fix hardware validation is pending.

Approach

What is the motivation for this PR?

Known-problem transceivers must skip direct LPMODE API validation, but they still require interface recovery after SFP reset. Treating both decisions as the same condition leaves the interfaces operationally down and causes the reset test and its BGP teardown to fail.

How did you do it?

Extracted the existing LPMODE skip-list match into should_skip_lpmode_check() and reused it when selecting interfaces to flap after reset. This keeps LPMODE API checks skipped for known-problem modules while still restoring their interfaces. The existing flat-memory handling on master remains unchanged.

How did you verify/test it?

Pre-commit hooks and Python compilation passed. The failure was reproduced on the 202511 image linked above; post-fix hardware validation is pending.

Any platform specific information?

Observed on Arista-7280DR3AM-36 with Cloud Light 7123-G37-01 transceivers. The change relies on the existing generic LPMODE_SKIP_LIST rather than hard-coding a platform.

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

Not a new test case. The failure was reproduced on t2_single_node_max.

Documentation

N/A

[azure-pipelines]

Azure Pipelines:
There may be pipelines that require an authorized user to comment /azp run to run.

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines:
1 pipeline(s) were filtered out due to trigger conditions.