Revert "[portsorch] Expose supported FEC modes to STABE_DB and check whether FEC mode is supported before setting it"

[prsunny]

Reverts #2333

Compilation issue observed - https://dev.azure.com/mssonic/build/_build/results?buildId=126119&view=logs&j=83516c17-6666-5250-abde-63983ce72a49&t=c10d5f44-55ce-55d7-7975-407ed75d9a96

[prsunny]

@stephenxs , can you check why/how it got passed in the original PR? Is there any gap in the build process?

[prgeor]

@prsunny, @stephenxs instead of reverting can we fix the issue as:-

https://github.com/Azure/sonic-swss/blob/master/orchagent/p4orch/tests/fake_portorch.cpp#L521

bool PortsOrch::setPortFec(Port &port, sai_port_fec_mode_t mode)
++bool PortsOrch::setPortFec(Port &port, std::string &mode)

[stephenxs]

@stephenxs , can you check why/how it got passed in the original PR? Is there any gap in the build process?

Yes.
This is a racing condition in the azure build process.
The compiling error occurred in orchagent/p4orch/tests/fake_portorch.cpp which was not part of the building at the time #2333 was being built in the azure pipeline last Thursday (Thu at 7:54 AM).
It has been added by PR #2375 which was merged also last Thursday but a bit later (Thu Jul 21 18:29:13 2022 -0700)

There is a way to guarantee such issues will be avoided and detected during building/merging,

• while merging a PR, rerun the test and block merging if there is an issue

but I believe it will slow down the process of opening/merging PR significantly because re-running the test takes several hours and it’s not always stable.
So this is a trade-off and I tend to treat the current way as the best for now:

• do not handle the racing condition
• revert the PR if an issue is detected.

BTW, PR #2400 is opened for taking the code back and resolving the compiling issue.

[prsunny]

@stephenxs , can you check why/how it got passed in the original PR? Is there any gap in the build process?

Yes. This is a racing condition in the azure build process. The compiling error occurred in orchagent/p4orch/tests/fake_portorch.cpp which was not part of the building at the time #2333 was being built in the azure pipeline last Thursday (Thu at 7:54 AM). It has been added by PR #2375 which was merged also last Thursday but a bit later (Thu Jul 21 18:29:13 2022 -0700)

There is a way to guarantee such issues will be avoided and detected during building/merging,

• while merging a PR, rerun the test and block merging if there is an issue

but I believe it will slow down the process of opening/merging PR significantly because re-running the test takes several hours and it’s not always stable. So this is a trade-off and I tend to treat the current way as the best for now:

• do not handle the racing condition
• revert the PR if an issue is detected.

BTW, PR #2400 is opened for taking the code back and resolving the compiling issue.

Thanks for your analysis @stephenxs . We are working with build team to see how this can be addressed in future.