[Mellanox] Update the sfp platform API to get the ext_specification_compliance with new way

[keboliu]

- Why I did it
In PR sonic-net/sonic-platform-common#112 updated the way to parse ext_specification_compliance, the platform API need to be updated accordingly.

- How I did it
Update the platform API implementation with calling dedicated parse function which defined in the platform-common.

- How to verify it
check whether xcvrd work normally
check CLI show transceiver output

- Which release branch to backport (provide reason below if selected)

• 201811
• 201911
• 202006

- Description for the changelog

- A picture of a cute animal (not mandatory but encouraged)

[keboliu]

this PR has a dependency on sonic-net/sonic-platform-common#112

[jleveque]

Is it possible to move this constant to the sonic_sfp package in sonic-platform-common, and have it tied to a specific parser, rather than having each vendor specify it? This would allow us to keep all of this data in the "bulk info" and would prevent future issues if we decide to parse more fields as part of the bulk info. We could also specify the offsets as constants as well, so that the vendor can reference them by name rather than using unnamed integers. What do you think of this proposal?

[keboliu]

it doable, but not sure whether it's applicable to other vendors? I didn't deep dive into it but it seems to me that some vendors implemented it in a quite different way, like DELL.
And for the OFFSET, in Mellanox implementation, is not the absolute OFFSET starting from the beginning of the eeprom, it's a relative one for the implementation convenience.

[jleveque]

it seems to me that some vendors implemented it in a quite different way, like DELL.

Yes, this is something I would like to avoid, and I feel that maybe defining these constants in the sonic_sfp package might prevent this, as all vendors would use the same constants.

And for the OFFSET, in Mellanox implementation, is not the absolute OFFSET starting from the beginning of the eeprom, it's a relative one for the implementation convenience.

Understood. If we define all of this in the sonic_sfp package, we would just have to make it clear. But the offsets should be fixed, not vendor specific, so I feel like these definitions belong as part of the sonic_sfp library itself.

[keboliu]

let me clarify, the current implementation is like this: in the vendor's implementation of the platform APIs, it read out the raw data from the EEPROM(with the given offset and width which defined by the constants we are talking about), and then feed the raw data to the parser functions defined in the common functions. So the idea is to move the definition of the offset and width to the platform common and when vendors read the EEPROM they should use the offset and width
constants defined in the platform common.

[jleveque]

This is along the lines of what I was thinking. As long as the offsets are only dependent on the SFP type, and are not vendor/platform-specific, we should abstract away the implementation as much as possible. We can take these changes for now to fix other vendors' implementations, and we can discuss this further offline.

[jleveque]

sonic-net/sonic-platform-common#112 has been merged. This PR now depends on the submodule update @ #5173