xcvrd: fix SFP monitor without get_transceiver_change_event() support

[ds952811]

This is a common approach for platforms without get_transceiver_change_event()
support, it will poll SFP module states with 1 second interval, and updates
the database accordingly

Otherwise, the xcvrd will crash right after initialization, as a result,
all the related services will fail.

e.g.

• SFP modules attached to the system after SONIC start-up, will not be detected
• SFP module information will never be updated upon removals

Signed-off-by: Dante (Kuo-Jung) Su dante.su@broadcom.com

• What I did
  For platforms without get_transceiver_change_event() support, fall back to periodically poll SFP module states for the SFP insertion/removal and the database updates

• How I did it

• Revise xcvrd to periodically poll SFP module states for the SFP insertion/removal and the database updates

• How to verify it

1. Bring up the DUT, and wait until SONIC CLI is ready
2. Please insert/remove SFP modules for multiple times
3. Issue the following command to check if SFP module insertion/removal is detected correctly
   show logging pmon -l 100

[msftclas]

All CLA requirements met.

[ds952811]

Please note the following change is also necessary for this commit, and it's for sonic-platform-common.

sonic-net/sonic-platform-common#37

[jleveque]

I have merged sonic-net/sonic-platform-common#37. Thanks for the fix!

Please resolve conflicts.

[jleveque]

@keboliu: Please review.

[keboliu]

@jleveque @ds952811

1. Vendors shall implement all the methods of plugins, this is by design. In this particular case, even platform not support SFP plug in/out event reporting, a dummy implementation shall be there to prevent xcvrd from crash.

2. If there is no event/interrupt for SFP on some certain platform, in this case the polling should be implemented inside the platform plugin, instead of polling SFP inside xcvrd, this is not something should be done by xcvrd.

3. In current xcvrd implementation, a new inserted SFP, if no event reported, eventually it's information will be added to DB by periodically running functions "post_port_dom_info_to_db" and "recover_missing_sfp_table_entries". It's true that SFP info will not be deleted if there is no event reported, but this is expected.

[jleveque]

Closing this PR as per comment above:

1. Vendors shall implement all the methods of plugins, this is by design. In this particular case, even platform not support SFP plug in/out event reporting, a dummy implementation shall be there to prevent xcvrd from crash.

2. If there is no event/interrupt for SFP on some certain platform, in this case the polling should be implemented inside the platform plugin, instead of polling SFP inside xcvrd, this is not something should be done by xcvrd.

3. In current xcvrd implementation, a new inserted SFP, if no event reported, eventually it's information will be added to DB by periodically running functions "post_port_dom_info_to_db" and "recover_missing_sfp_table_entries". It's true that SFP info will not be deleted if there is no event reported, but this is expected.