[sonic_xcvr] Fix temperature capability and readiness handling

[ArthurMicas]

What I did

Correct temperature capability and readiness handling in the common transceiver APIs. A failed capability read now returns None instead of being reported as unsupported or assumed to support temperature monitoring.

• Read CMIS Page 01h byte 159 bit 0 after checking the memory model.
• Check SFF-8472 A2h byte 110 Data_Not_Ready before reading temperature.
• Preserve failed copper detection in SFF-8436/SFF-8636 and use the raw SFF-8636 revision to honor byte 220 bit 5 for revision codes 0x08 and later.
• Return None when QSFP revision detection fails, and extend factory dispatch for legacy QSFP/microQSFP and additional CMIS identifiers while preserving the requested bank.
• Add capability, readiness, raw EEPROM, recovery, and factory dispatch regressions; update the existing CMIS capability test to call the real method instead of a shared mock.

Existing copper-module policy and the pre-2.8 SFF-8636 temperature assumption are preserved. These changes are limited to sonic-platform-common; no platform sfputil or installation scripts are included.

How I verified it

On Ubuntu 22.04 / Python 3.10:

• Directly affected API and factory tests: 624 passed.
• python3 -m pytest -o addopts= tests/sonic_xcvr --ignore=tests/sonic_xcvr/test_bailly_optoe_base.py -q --disable-warnings --cov=sonic_platform_base.sonic_xcvr: 1514 passed.
• All 44 changed executable lines reported by coverage.py were covered; the exercised sonic_xcvr tree had 88% statement coverage.
• git diff --check: passed.

The unfiltered sonic_xcvr run could not collect test_bailly_optoe_base.py because the local environment lacks the native SONiC swsscommon dependency. That file was explicitly excluded from the 1514-test run. The full repository suite and hardware validation were not run. New identifier tests validate dispatch and bank propagation, not complete hardware qualification of each module family.

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

[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}

[bgallagher-nexthop]

LGTM 👍

[bgallagher-nexthop]

Can you leave this one undefined in the id_mapping? ELSFPs currently have their own API class separate to CmisApi which is instantiated via a different factory class

[ArthurMicas]

Deleted both elsfp and xpo's mapping in new commit

[bgallagher-nexthop]

I think these tests might better belong split into multiple files:

• test_cmis.py for CMIS test cases
• test_sff8436.py for SFF-8436 test cases
• test_sff8472.py for SFF-8472 test cases
• test_sff8636.py for SFF-8636 test cases

otherwise a precedent is set to have a test file per capability (e.g test_vcc_support) spanning each API

[ArthurMicas]

Done, thanks for the tip!

[mssonicbld]

/azp run

[azure-pipelines]

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

[mssonicbld]

/azp run

[azure-pipelines]

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

[mssonicbld]

/azp run

[azure-pipelines]

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