Add deterministic bringup for SFF compliant modules

[longhuan-cisco]

Note
For review internally only
PLEASE DO NOT MERGE.

Description

According to Interface-Link-bring-up-sequence.md, add a new thread sff_mgr under xcvrd for deterministic bringup on SFF compliant modules (100G/40G).

By default sff_mgr is disabled, to enable sff_mgr on a platform, add and set 'enable_xcvrd_sff_mgr' to true in pmon_daemon_ctrl json file.

Motivation and Context

• Scope of sff_mgr: 100G/40G optics (copper/aoc not in the scope)

• Why sff_mgr
  The goal of sff_mgr is to make sure SFF compliant modules are brought up
  in a deterministc way, meaning TX is enabled only after host_tx_ready
  becomes True, and TX will be disabled when host_tx_ready becomes False.
  This will help eliminate link stability issue and potential interface
  flap, also turning off TX reduces the power consumption and avoid any
  lab hazard for admin shut interface.

• What sff_mgr does
  sff_mgr is a new thread inside Xcvrd.
  sff_mgr will only proceed at two events: transceiver insertion event
  (including bootup and hot plugin) and host_tx_ready change event, all
  other cases are ignored. If either of these two events is detected,
  sff_mgr will determine the target tx_disable value based on
  host_tx_ready, and also check the current HW value of tx_disable/enable,
  if it's already in target tx_disable/enable value, no need to take
  action, otherwise, sff_mgr will set the target tx_disable/enable value
  to HW.
  To detect these two events, sff_mgr listens to below DB tables, and
  mantains a local copy of those DB values, stored in self.port_dict. In
  each round of task_worker while loop, sff_mgr will calculate the delta
  between current self.port_dict and previous self.port_dict (i.e.
  self.port_dict_prev), and determine whether there is a change event.
  1. STATE_DB PORT_TABLE's 'host_tx_ready' field for host_tx_ready
  change event.
  2. STATE_DB TRANSCEIVER_INFO table's 'type' field for insesrtion
  event. Since TRANSCEIVER_INFO table has the same life cycle of
  transceiver module insertion/removal, its DB entry will get
  created at xcvr insertion, and will get deleted at xcvr removal.
  TRANSCEIVER_STATUS table can also be used to detect
  insertion/removal event, but 'type' field of TRANSCEIVER_INFO
  table can also be used to filter out unwanted xcvr type, thus
  TRANSCEIVER_INFO table is used here.
  On the other hand, sff_mgr also listens to CONFIG_DB PORT_TABLE for info
  such as 'index'/etc.

• For platforms/vendors:
  There is a behavior change (and requirement) for the platforms that
  enable this sff_mgr feature: platform needs to keep TX in disabled state
  after module coming out-of-reset, in either module insertion or bootup
  cases. This is to make sure the module is not transmitting with TX
  enabled before host_tx_ready is True. No impact for the platforms in
  current deployment (since they don't enable it explictly.)
  Platform can decide whether to enable sff_mgr via platform
  enable_sff_mgr flag. If enable_sff_mgr is False, sff_mgr will not run.

How Has This Been Tested?

1. Under sff_mgr enabled platform, verify tx is enabled/disabled properly based on host_tx_ready and in proper order under module OIR/bootup/process restart cases.
2. verify tx is enabled/disabled properly along with "config interface shutdown/startup" (which changes admin_status and host_tx_ready value)
3. verify no impact on platform without sff_mgr enabled.

Additional Information (Optional)

[longhuan-cisco]

Move into new file