Refactor CMIS memory map into pages

[aditya-nexthop]

Cherry pick commits from nexthop-ai#1 to public fork since it wasn't possible to move the original PR to sonic-net

This PR implements part 1 of 2 of the HLD described here.
It introduces the CmisPage class and refactors CMIS Mem Map into pages

Description

Refactor the CMIS memory map from a single monolithic class into per-page
classes that each own their own field definitions.

• Introduces a new sonic_platform_base/sonic_xcvr/mem_maps/public/cmis_pages/
  package with one module per CMIS page:
  • pg_00_administrative_lower.py / pg_00_administrative_upper.py
  • pg_01_advertising.py
  • pg_02_thresholds.py
  • pg_10_lane_datapath_config.py
  • pg_11_lane_datapath_status.py
  • pg_12_tunable_laser_ctrl_status.py
  • pg_13_module_perf_diag_ctrl.py
  • pg_2f_vdm_advertising_ctrl.py
  • pg_9f_cdb_message.py
• Adds a CmisPage base class (cmis_pages/base.py) that:
  • Stores its own page and bank numbers.
  • Implements getaddr(offset, page_size) so each page computes linear
    EEPROM offsets locally instead of relying on CmisFlatMemMap.getaddr.
  • Provides register_fields(memmap), which composes the page's fields
    onto the parent memory map and merges shared RegGroupFields (e.g.
    ADMIN_INFO_FIELD, ADVERTISING_FIELD) that span multiple pages,
    re-sorting members by offset to preserve the RegGroupField invariant.
• Adds cmis_pages/cmis_page_consts.py with CMIS layout constants
  (CMIS_EEPROM_PAGE_SIZE, CMIS_ARCH_PAGES,
  CMIS_NUM_NON_BANKED_PAGES, and page-number constants).
• Reworks cmis.py:
  • CmisFlatMemMap now exposes an add_pages(*pages) helper that appends
    to self.pages and calls register_fields on each page.
  • CmisFlatMemMap composes only the lower and upper halves of page 0x00.
  • CmisMemMap extends it by adding pages 0x01, 0x02, 0x10–0x13, 0x2F,
    and 0x9F.
  • getaddr now takes page as an explicit parameter and clamps bank
    to 0 for non-banked pages (00h–0Fh) and CDB pages (9Fh–AFh).
• Registers the new cmis_pages package in setup.py.

Net diff: cmis.py shrinks from ~720 lines to ~120 lines, with the field
definitions redistributed across the per-page modules.

Motivation and Context

The previous CmisFlatMemMap / CmisMemMap implementation defined every
field for every CMIS page inside a single ~700-line class. This made it
hard to:

• Locate the fields belonging to a given page.
• Compose alternative memory maps (e.g. flat vs. paged, per-bank variants)
  without duplicating large blocks of field definitions.
• Re-map an entire page (for vendor-specific layouts or future CMIS
  revisions) without editing the monolithic class.

Splitting the map into per-page classes makes each page self-contained
and addressable, lets CmisFlatMemMap and CmisMemMap declare their
contents by listing the pages they include, and allows shared field
groups that cross page boundaries (like ADMIN_INFO_FIELD spanning lower
and upper page 00h, or ADVERTISING_FIELD spanning pages 01h and 11h)
to be merged automatically by register_fields.

Exposing the page number as a constructor parameter on each page class
also enables entire pages to be remapped easily without duplicating field
declarations.

How Has This Been Tested?

This change introduces no new fields or changes in behavior.
All the existing unit tests pass.

Additional Information (Optional)

This change is intended to be behavior-preserving: the resulting
CmisMemMap exposes the same set of named fields at the same EEPROM
offsets as before the refactor. Only the internal organization of the
memory map definition changes.

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

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[prgeor]

@aditya-nexthop may I suggest to have following dir style?

../public/cmis/pages/

page00.py
page01.py
page02.py
...
...
...
page2f.py
page9f.py

../public/cmis/cmis.py

The page file anywas has comment to indicate what this memmap corresponds to.

[aditya-nexthop]

updated

[aditya-nexthop]

I realized that this changes the location of cmis.py that holds theCmisFlatMemMap and CmisMemMap from sonic_platform_base/sonic_xcvr/mem_maps/public/cmis.py to sonic_platform_base/sonic_xcvr/mem_maps/public/cmis/cmis.py.

We now have a divergence where, cmis.py is inside the cmis directory while cdb.py and c_cmis.py is still in sonic_platform_base/sonic_xcvr/mem_maps/public/. I recommend all of them are at the same depth.

Where should we put them? Inside cmis or outside?

[prgeor]

@aditya-nexthop have we considered if any impact to link up time (fully loaded system), dom polling interval, link initialization when single optics insertion. A comparison will be good.

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).