[202511] [xcvrd] Support mixed application codes in CMIS decommission logic (#794)

[mihirpat1]

Cherry-pick of #794 to 202511.

Description

The original is_decommission_required() compared all 8 module lanes against a
single application code (app_new) — the app code of whichever logical port
triggered the check. On an OSFP-8X module configured with mixed breakout
(e.g., 1x400G on lanes 0-3 + 4x100G on lanes 4-7), lanes belonging to sibling
ports have a different valid app code. The old logic saw
current_app != app_new on those sibling lanes and returned True,
triggering an unnecessary decommission cycle.

Motivation and Context

Fix — Two changes in cmis_manager_task.py:

1. New method get_desired_app_map(api, lport) — reads CONFIG_DB PORT table
   to find all sibling logical ports on the same physical port (matched by
   index). For each sibling, resolves the desired CMIS application code and
   lane mask, building a per-lane desired app map (e.g. [3,3,3,3,1,1,1,1]).
2. Revised is_decommission_required(api, lport) — accepts lport instead
   of app_new, calls get_desired_app_map(), and compares each lane's
   current app against its per-lane desired app. Lanes currently unused
   (AppSel=0) are ignored.

How Has This Been Tested?

Cherry-pick conflict resolution notes: 202511 differs from master in two
pre-existing ways unrelated to #794 (kept unchanged here):

• 202511 uses self.is_fast_reboot_enabled = False instance attribute
  (master refactored to lazy accessor _is_fast_reboot_enabled).
• 202511 keeps the monolithic process_single_lport; master split it into
  handle_cmis_inserted_state / handle_cmis_dp_pre_init_check_state /
  handle_cmis_dp_deinit_state / process_cmis_state_machine.

The functional PR #794 changes (get_host_lane_count,
get_sibling_port_configs, get_desired_app_map, is_decommission_required)
are byte-for-byte identical to master. Call-site updates in the monolithic
process_single_lport (drop gearbox_lanes_dict param; call
is_decommission_required(api, lport)) applied.

Original PR testing (from #794): non-breakout baseline, sfputil reset + SNS,
xcvrd/pmon/swss restart, config reload, device reboot, loopback,
admin shut/no-shut, and DPB (1x800G ↔ 2x400G ↔ 4x200G ↔ 8x100G, 50
iterations each direction).

Additional Information (Optional)

MSFT ADO - 37489480

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

[Copilot]

Pull request overview

This PR cherry-picks the fix from #794 into the 202511 branch to prevent unnecessary CMIS decommission cycles on OSFP-8X modules configured with mixed breakout by computing a per-lane “desired app code” map across sibling logical ports and comparing against each lane’s active AppSel.

Changes:

• Add CONFIG_DB-backed sibling port discovery and build a per-lane desired application-code map (get_sibling_port_configs(), get_desired_app_map()).
• Update is_decommission_required() to accept lport, compare lane-by-lane against the desired map, and ignore unused lanes (AppSel=0).
• Cache gearbox lane-count data once per task_worker iteration and update call sites/tests accordingly.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
sonic-xcvrd/xcvrd/cmis/cmis_manager_task.py	Adds sibling-port CONFIG_DB lookup and per-lane desired app mapping; updates decommission decision logic; introduces per-iteration gearbox lane-count caching.
sonic-xcvrd/tests/test_xcvrd.py	Updates and expands unit tests to cover mixed-mode per-lane decommission logic and the new gearbox-lane cache usage.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.