[ycabled][active-standby] Ignore transceiver updates for initialized MUX simulator.

[harjotsinghpawra]

Description

TRANSCEIVER_INFO SET notifications contain the complete table row and are
generated for both transceiver insertion and CMIS maintenance updates. After
a simulated Y-cable is initialized, treating every SET as an insertion causes
ycabled to reread the simulator direction and publish stale HW MUX state.

Ignore SET notifications only when the simulator configuration exists and the
port already has a fully initialized simulated Y-cable instance. Continue to
process initial discovery, failed-initialization retries, and DEL notifications.

Add unit tests for initialized, missing, incomplete, and unconfigured simulator
instances and for the corresponding state-update behavior.

Motivation and Context

Problem

xcvrd publishes TRANSCEIVER_INFO SET notifications for CMIS maintenance updates during downlink admin-down. ycabled treats every SET as an SFP insertion. For an active-standby simulated Y-cable this rereads the simulator MUX direction and updates STATE_HW_MUX_CABLE with a direction that may lag linkmgrd's requested state. The stale update can cause active/standby MUX ping-pong and exceed the dual-ToR traffic disruption budget.

Root cause

SubscriberStateTable returns the complete current table row for a SET, not only the changed fields. Consequently, filtering the event based on the fields present in the returned dictionary cannot reliably distinguish insertion from a CMIS-only update.

Fix

For simulator-backed ports, treat a SET as an insertion only until the simulated Y-cable driver is fully initialized. Once the driver instance exists and _initialized is True, ignore subsequent TRANSCEIVER_INFO SET notifications.

The guard is deliberately limited to the MUX simulator by requiring /etc/sonic/mux_simulator.json. Physical Y-cable behavior remains unchanged. DEL notifications remain unchanged and remove the saved driver instance, so a later insertion can initialize again. Missing or partially initialized instances return False, allowing later notifications to retry initialization.

How Has This Been Tested?

• Initialized simulator suppresses repeated SET processing.
• Missing simulator instance permits initial discovery.
• Incomplete simulator instance permits retry.
• Missing simulator configuration preserves existing behavior.
• Removal processing remains unchanged through the existing DEL test.

The ycabled wheel build automatically ran the complete component test suite inside the SONiC build container:

platform linux -- Python 3.13.5, pytest-8.3.5
collected 280 items
280 passed, 144 warnings in 6.75s

New tests recorded as passing:

tests/test_y_cable_helper.py::TestYCableScript::test_is_initialized_simulated_y_cable PASSED
tests/test_y_cable_helper.py::TestYCableScript::test_is_initialized_simulated_y_cable_without_instance PASSED
tests/test_y_cable_helper.py::TestYCableScript::test_is_initialized_simulated_y_cable_incomplete_instance PASSED
tests/test_y_cable_helper.py::TestYCableScript::test_is_initialized_simulated_y_cable_without_config PASSED
tests/test_ycable.py::TestYcableScript::test_handle_state_update_task_ignores_update_for_initialized_simulator PASSED
tests/test_ycable.py::TestYcableScript::test_handle_state_update_task_processes_update_for_uninitialized_simulator PASSED
tests/test_ycable.py::TestYcableScript::test_handle_state_update_task_retries_cmis_update_after_failed_simulator_init PASSED

#### Additional Information (Optional)

[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).

[mssonicbld]

Hi, there are workflow run(s) waiting for approval, you may be first-time contributor. I will notify maintainers to help approve once PR is approved. Thanks!

_{---Powered by SONiC BuildBot}

[harjotsinghpawra]

@lolyu can you please help review this

[zjswhhh]

Please make sure the initialized flag will be reset for actual unplug/insert.

[zjswhhh]

The fix is applicable to both simulated and physical mux scenario.

[harjotsinghpawra]

@zjswhhh I am working on the hardware fix as well , there might some race conditions while maintaining instialized list looking into it

[mssonicbld]

/azp run

[azure-pipelines]

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

[harjotsinghpawra]

@zjswhhh I have made changes for hardware also , it also uses y_cable_helper functions i have put ports in intialization there . Can you review and test on actual hardware if it breaks anything as i dont have actual hardware mux cable ?