[dut_basic_facts]: resolve real release (YYYYMM) from build_version on unstamped images

[deepak-singhal0408]

Description of PR

Summary:
On images without /etc/sonic/sonic_release (all VS/KVM and self-built images), the release fact produced by ansible/library/dut_basic_facts.py is guessed from build_version. The old fallback only recognized 201811, 201911, and master, so every other release (202012 … 202605) collapsed to "unknown" — even though build_version starts with the release token (e.g. 202605.1166406-...).

Because the release fact is what the conditional_mark plugin evaluates, release-based skips such as release in ['202605', ...] silently never matched on VS, so tests intended to be skipped there ran anyway. This surfaced while triaging the CI failure on #26270. This PR fixes the fallback so release resolves to the real YYYYMM release on unstamped/VS images.

Type of change

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

Back port request

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

Approach

What is the motivation for this PR?

Make release-based conditional_mark conditions work correctly on VS/KVM (and any self-built) images. Today they can never match because release resolves to "unknown" on those images, which makes release-gated skips a silent no-op on VS.

How did you do it?

Extracted the release resolution into a pure, dependency-free helper ansible/module_utils/sonic_release_utils.py::guess_release_from_build_version(): an already-stamped release (real HW) is returned unchanged; otherwise a leading YYYYMM token is extracted via re.match(r'(20\d{4})', ...) (202605.1166406-... -> 202605; old date-stamped 20181130.31 -> 201811); master in build_version -> master; anything else -> unknown. ansible/library/dut_basic_facts.py now imports and calls the helper (mirroring the existing parse_utils import guard), replacing the hard-coded 201811/201911/master ladder.

How did you verify/test it?

Added ansible/module_utils/test_sonic_release_utils.py — 62 parametrized cases covering all modern releases, old date-stamped images, master, precedence of an already-stamped release, unparseable -> unknown, build-number-not-confused, and a regression guard that 202605 no longer collapses to unknown: python3 -m pytest --noconftest ansible/module_utils/test_sonic_release_utils.py -> 62 passed. flake8 --max-line-length=120 clean; py_compile OK.

Any platform specific information?

Only affects the release fact derivation for images lacking /etc/sonic/sonic_release (VS/KVM, self-built). Real-HW images that stamp release are unchanged. Old-release exclusion lists are unaffected; the intended effect is that current-release skips now correctly fire on VS.

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

N/A (framework fix).

Documentation

No.

[mssonicbld]

/azp run

[azure-pipelines]

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

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).

[StormLiangMS]

LGTM

[mssonicbld]

Cherry-pick PR to 202605: #26445

[mssonicbld]

This PR has backport request label(s) for branch(es): 202605, but is missing required test information. Please make sure you tick the tested branch(es) in the Tested branch section and provide test evidence (e.g., 202605: <test result>) in the Test result section as well in your PR description.

_{---Powered by SONiC BuildBot}