[redfish] Prove PowerCycle by the switch host boot id

[shreyansh-nexthop]

Description of PR

Summary:
test_reset_power_cycle asserted that the switch host's oper status goes Offline during a Redfish PowerCycle. That off-window is not observable through the platform API on every platform: get_oper_status() reflects power state, which on some BMCs derives from a power-down latch that a pwr_cycle pulse never sets. Where the window is observable, catching one to two seconds of it with a one second poll is a race.

This replaces the two transition polls with a boot-id oracle. The switch host's boot id changes only on an actual restart, so the test proves the cycle happened without depending on a platform-specific reset-pin reading.

Related: #27212

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):
Failure type:

Tested branch

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

Test result

master: verified on a SONiC BMC testbed (bmc-shared-mgmt topology). All 5 tests in tests/redfish/test_redfish_computer_reset.py pass, including test_reset_power_cycle, which now proves the cycle by the switch host boot id changing.

Approach

What is the motivation for this PR?

The old assertion is not guaranteed by the platform contract. Oper status for the switch host module reflects power state, and on latch-based platforms a power-cycle pulse never drives it Offline, so the assertion cannot be satisfied there. On platforms where it is observable, the window is short enough that the poll can miss it.

How did you do it?

Read the switch host's boot id from /proc/sys/kernel/random/boot_id before issuing the reset, then wait for it to change. A host that is down mid-cycle is unreachable rather than returning a value, so the read reports None in that state and the wait continues instead of registering a change. A BMC that silently no-ops the API leaves the boot id untouched and the test fails, which is the case the original assertion existed to catch.

The host object is resolved lazily through a fixture, because a preceding test in the class can leave the host still booting, and building the object gathers facts over SSH. The resolve wait and the post-reset boot wait use separate budgets so a host that never returns cannot consume both.

How did you verify/test it?

Ran the full tests/redfish/test_redfish_computer_reset.py suite on a SONiC BMC testbed; all 5 tests pass.

Any platform specific information?

The test targets BMC topologies (pytest.mark.topology('bmc')). The change removes a dependency on platform-specific reset-pin observability, so it applies to BMC platforms whose oper status does not expose the power-cycle window.

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

Not a new test case.

Documentation

No documentation change needed.

[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:
Successfully started running 1 pipeline(s).

[azure-pipelines]

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

[azure-pipelines]

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

[nikamirrr]

@nhe-NV would you please ask someone to review?