…es (#176)

<!--
 Please make sure you've read and understood our contributing guidelines:
 https://github.com/Azure/SONiC/blob/gh-pages/CONTRIBUTING.md

 failure_prs.log skip_prs.log Make sure all your commits include a signature generated with `git commit -s` **

 If this is a bug fix, make sure your description includes "closes #xxxx",
 "fixes #xxxx" or "resolves #xxxx" so that GitHub automatically closes the related
 issue when the PR is merged.

 If you are adding/modifying/removing any command or utility script, please also
 make sure to add/modify/remove any unit tests from the tests
 directory as appropriate.

 If you are modifying or removing an existing 'show', 'config' or 'sonic-clear'
 subcommand, or you are adding a new subcommand, please make sure you also
 update the Command Line Reference Guide (doc/Command-Reference.md) to reflect
 your changes.

 Please provide the following information:
-->

#### What I did
1. With the recent transceiver DOM and STATUS table related changes, the handles of the following CLIs need to be modified to ensure that the CLI function inline to the existing behavior
 1. show int transceiver eeprom -d
 2. show int transceiver status
 3. show int transceiver pm
 4. sfputil show eeprom -d -p EthernetXX

2. Also, all the diagnostics related tables will not be present only for the first subport for breakout ports. Hence, made the corresponding CLI handler related changes to support this
3. Modified the `sfputil show error-status` CLI handler to use `TRANSCEIVER_STATUS_SW` instead of `TRANSCEIVER_STATUS` table

#### How I did it
1. Replaced function call for get_transceiver_bulk_status with get_transceiver_dom_real_value
5. As part of displaying o/p for "show int transceiver status" CLI, we are now fetching data from TRANSCEIVER_DOM_FLAG, VDM flag tables and TRANSCEIVER_STATUS_FLAG tables as well since the relevant fields have been moved to these new tables
6. As part of display o/p for "show int transceiver pm" CLI, we are now fetching data from VDM threshold tables as well since the relevant fields have been moved to these new tables

Related PRs
sonic-net/SONiC#1954
[[cmis] Separate Flag-Specific Fields for DOM and Status APIs by mihirpat1 · Pull Request #556 · sonic-net/sonic-platform-common](sonic-net/sonic-platform-common#556)
[[xcvrd] Re-organize transceiver DOM and STATUS tables by mihirpat1 · Pull Request #604 · sonic-net/sonic-platform-daemons](sonic-net/sonic-platform-daemons#604)

#### How to verify it
Following tests were attempted and confirmed to pass

1. Diagnostic table related verification
	1. Compare tables with nightly image and ensure non-CMIS transceivers do not change their mapping for DOM and status tables
	2. Compare DOM sensor, threshold and status tables between current and nightly. Ensure units are not shown
	3. Dump TRANSCEIVER_INFO table for CMIS transceiver to ensure is_replaceable field is present
2. CLI verification
	1. sudo sfputil show error-status - This should dump output for all the ports and the behavior should not change between nightly and private image
	2. Use invalid port name (Ethernet2033) to dump show int transceiver info, status CLI. Ensure to note new errors in PR description for invalid ports
	3. For breakout scenario, keep 2 subports in different CMIS_STATES and ensure the CLI o/p is different for status CLI for both subports
3. Run transceiver onboarding test due to TRANSCEIVER_INFO table deletion change
4. XCVRD stop/start
	1. Stop xcvrd and ensure all diagnostic tables are deleted
	2. Start xcvrd and ensure all diagnostic tables are populated
5. Link flap event handling
	1. Change link flap count for different types of transceivers and ensure no crash is seen. This is to ensure that the link event handler code does not cause any crash for non-CMIS transceivers
	2. Shutdown peer port and ensure the tables get updated which are handled via link event update handler.
		Also, execute sfputil reset on 10 different physical ports and ensure that all the corresponding flags on the remote side are updated for all 8 lanes of a DR8 optic
		Specifically, we need to ensure that the following flags are set wherein X represents the lane number
		1. LOSFlagRxX (page 11, byte 147)
		2. CDRLOLFlagRxX (page 11, byte 148)
		3. OpticalPowerLowAlarmFlagRxX (page 11, byte 150)
		4. OpticalPowerLowWarningFlagRxX (page 11, byte 152)
6. Transceiver OIR test
	1. Remove transceiver and ensure all diagnostic related tables are deleted
	2. Insert transceiver and ensure all diagnostic tables are populated
	3. Stop xcvrd and remove transceiver and ensure TRANSCEIVER_INFO table is present. Start xcvrd and ensure that the TRANSCEIVER_INFO table is now deleted
	4. Insert the transceiver now
7. Ensure firmware upgrade is successfull and TRANSCEIVER_FIRMWARE_INFO table changes only for the primary subport eventhough, the upgrade was triggered for a non-primary subport
8. Ensure SFF manager crash is seen with nightly and is resolved with this PR (since the PR has the fix for [SffLoggerForPortUpdateEvent class does not have log_debug function · Issue #605 · sonic-net/sonic-platform-daemons](sonic-net/sonic-platform-daemons#605))

#### Previous command output (if the output of a command-line utility has changed)
The output of show int transceiver info and show int transceiver eeprom will change if an invalid port name is passed to the CLI

```
root@str4-sn5600-3:/home/admin# show int transceiver info Ethernet8
Ethernet8: SFP EEPROM Not detected
root@str4-sn5600-3:/home/admin#
```

#### New command output (if the output of a command-line utility has changed)
```
root@str4-sn5600-3:/home/admin# show int transceiver info Ethernet8
Error: Found KeyError while getting first subport for Ethernet8
Error: Unable to get first subport for Ethernet8 while converting SFP info
Ethernet8: SFP EEPROM Not detected
root@str4-sn5600-3:/home/admin#
```
MSFT ADO - 32238285

The changes to the sonic-mgmt testcases are required due to the below
changes:
sonic-net/sonic-platform-common#556
sonic-net/sonic-platform-daemons#604
sonic-net/sonic-utilities#3844

This PR also reverts the changes made by #181 .

<!-- Provide a general summary of your changes in the Title above -->

#### Description
<!--
     Describe your changes in detail
-->

Remove calls to setting a syslog tag as there was no logging actually used in this module. The existing call to log a message was in dead code, therefore there was no need to setup a syslogger at all.

#### Motivation and Context
<!--
     Why is this change required? What problem does it solve?
     If this pull request closes/resolves an open Issue, make sure you
     include the text "fixes #xxxx", "closes #xxxx" or "resolves #xxxx" here
-->
In python services using `sonic_py_common.logger` the syslog identifier already set up by the executable/service can be overwritten when importing other modules.

This log hijack is coming from a library: `sonic_platform_base/sonic_xcvr/api/public/c_cmis.py`
```
SYSLOG_IDENTIFIER = "CCmisApi"
...
helper_logger = logger.Logger(SYSLOG_IDENTIFIER)
# This is the only log that this file has:
    helper_logger.log_debug('key {} not present in VDM'.format(new_key))
```

Searching in the syslog of a switch running SONiC we see logs with the `CCmisApi` that shouldn't:
```
2025-11-11T13:20:03.440479+00:00 sonic CCmisApi: Failed to load platform Pcie module. Warning : No module named 'sonic_platform.pcie', fallback to load Pcie common utility.
2025 Nov 11 13:20:45.179454 gold228 NOTICE CCmisApi: System is ready
```

If any code imports c_cmis.py (indirectly for the most part) and has a logger session open already, their existing session will be re-opened with a new log tag, `CCmisApi` which is not desired.

To fix this we remove this logging code entirely because the function where it is used became dead in sonic-net#556

Libraries (rather than executables) probably shouldn't be syslogging on their own, and they certainly shouldn't hijack the log tag of the including executable.

Resolves sonic-net/sonic-buildimage#24489

#### How Has This Been Tested?
<!--
     Please describe in detail how you tested your changes.
     Include details of your testing environment, and the tests you ran to
     see how your change affects other areas of the code, etc.
-->
Before the fix:
Open an interactive python session and run this code:
```
from sonic_py_common import logger
log = logger.Logger("NATE")
log.log_notice("Log 1")
import sonic_platform
log.log_notice("Log 2")
```
Watch the syslog output:
```
2025 Nov 11 13:47:29.002667 gold228-dut NOTICE NATE: Log 1
2025 Nov 11 13:48:28.406481 gold228-dut NOTICE CCmisApi: Log 2
```
Clearly the second log should also have had the tag `NATE`

After the fix:
Syslog entries should have been:
```
2025 Nov 11 13:47:29.002667 gold228-dut NOTICE NATE: Log 1
2025 Nov 11 13:48:28.406481 gold228-dut NOTICE NATE: Log 2
```

Signed-off-by: Sonic Build Admin <sonicbld@microsoft.com>
#### Additional Information (Optional)

<!-- Provide a general summary of your changes in the Title above -->

#### Description
<!--
 Describe your changes in detail
-->

Remove calls to setting a syslog tag as there was no logging actually used in this module. The existing call to log a message was in dead code, therefore there was no need to setup a syslogger at all.

#### Motivation and Context
<!--
 Why is this change required? What problem does it solve?
 If this pull request closes/resolves an open Issue, make sure you
 include the text "fixes #xxxx", "closes #xxxx" or "resolves #xxxx" here
-->
In python services using `sonic_py_common.logger` the syslog identifier already set up by the executable/service can be overwritten when importing other modules.

This log hijack is coming from a library: `sonic_platform_base/sonic_xcvr/api/public/c_cmis.py`
```
SYSLOG_IDENTIFIER = "CCmisApi"
...
helper_logger = logger.Logger(SYSLOG_IDENTIFIER)
# This is the only log that this file has:
 helper_logger.log_debug('key {} not present in VDM'.format(new_key))
```

Searching in the syslog of a switch running SONiC we see logs with the `CCmisApi` that shouldn't:
```
2025-11-11T13:20:03.440479+00:00 sonic CCmisApi: Failed to load platform Pcie module. Warning : No module named 'sonic_platform.pcie', fallback to load Pcie common utility.
2025 Nov 11 13:20:45.179454 gold228 NOTICE CCmisApi: System is ready
```

If any code imports c_cmis.py (indirectly for the most part) and has a logger session open already, their existing session will be re-opened with a new log tag, `CCmisApi` which is not desired.

To fix this we remove this logging code entirely because the function where it is used became dead in #556

Libraries (rather than executables) probably shouldn't be syslogging on their own, and they certainly shouldn't hijack the log tag of the including executable.

Resolves sonic-net/sonic-buildimage#24489

#### How Has This Been Tested?
<!--
 Please describe in detail how you tested your changes.
 Include details of your testing environment, and the tests you ran to
 see how your change affects other areas of the code, etc.
-->
Before the fix:
Open an interactive python session and run this code:
```
from sonic_py_common import logger
log = logger.Logger("NATE")
log.log_notice("Log 1")
import sonic_platform
log.log_notice("Log 2")
```
Watch the syslog output:
```
2025 Nov 11 13:47:29.002667 gold228-dut NOTICE NATE: Log 1
2025 Nov 11 13:48:28.406481 gold228-dut NOTICE CCmisApi: Log 2
```
Clearly the second log should also have had the tag `NATE`

After the fix:
Syslog entries should have been:
```
2025 Nov 11 13:47:29.002667 gold228-dut NOTICE NATE: Log 1
2025 Nov 11 13:48:28.406481 gold228-dut NOTICE NATE: Log 2
```

Signed-off-by: Sonic Build Admin <sonicbld@microsoft.com>
#### Additional Information (Optional)