[Accton][minipack3bta] Add runtime asic feature support override via gflag

[jeankuo]

Pre-submission checklist

• [v] I've ran the linters locally and fixed lint errors related to the files I modified in this PR. You can install the linters by running pip install -r requirements-dev.txt && pre-commit install
• [v] pre-commit run

Summary

Add runtime feature support override mechanism via gflag --asic_feature_support_overrides for TomahawkUltra1 ASIC.

This allows overriding individual HwAsic::Feature support at runtime without code changes, enabling faster platform bring-up and SDK compatibility testing. The override is specified as comma-separated FEATURE_ID=true|false pairs.

Changes:

• Add getFeatureSupportOverride() protected method in HwAsic base class
• Add logFeatureSupportOverrides() to log active overrides at startup
• Integrate override check in TomahawkUltra1Asic::isSupported()

Test Plan

• Build and run SAI agent with no flag: no behavioral change, no log output
• Run with --asic_feature_support_overrides 73=false: feature reported as unsupported and FeatureOverride log lines appear at startup
• Run with invalid/empty values: graceful handling, no crash
• Verify removing the flag restores original feature support behavior

test_log.txt

[daiwei1983]

Can you tell me more about the use case, when you might want to dynamically turn on/off hw features at run time pretty often?

Ideally, these HwAsic features just tell whether the ASIC is capably of supporting this feature from hardware point of view. Whether this feature is really enabled or not is determined by separate feature gflag. So, HwAsic feature support is more like static hardware spec information never changes. It makes more sense to dynamically guard feature on/off using gflag.

[jeankuo]

Add runtime feature support override mechanism via gflag --asic_feature_support_overrides for TomahawkUltra1 ASIC.

This allows overriding individual HwAsic::Feature support at runtime without code changes, enabling faster platform bring-up and SDK compatibility testing. The override is specified as comma-separated FEATURE_ID=true|false pairs.

Hi @daiwei1983,

Thanks for the review! Let me clarify the use case.

You're right that HwAsic::isSupported() represents static hardware capability and shouldn't change in normal operation. This override is not intended for production feature toggling.

The use case is during new platform bring-up and SDK compatibility testing. When we bring up a new ASIC/SDK version (e.g., TomahawkUltra1 with a newer Memory SDK), we sometimes encounter situations where:

1. A feature is declared as supported in the ASIC class, but the SDK version we're testing against doesn't actually implement it yet (or has a regression).
2. We need to quickly verify whether a failure is caused by a specific feature being incorrectly reported as supported/unsupported, without rebuilding the binary.

Rebuilding and redeploying the agent binary on lab switches takes significant time. This gflag lets us temporarily mask a feature to isolate issues during debugging, without code changes or recompilation.

Also worth noting: currently the override is only integrated into TomahawkUltra1Asic::isSupported() — it does not affect any other ASIC classes. The scope is intentionally limited to the platform we're actively bringing up, minimizing any risk to existing platforms.

Once bring-up is complete and the correct feature set is confirmed, the flag is not used — it defaults to empty string (no-op). The WARNING-level logging also makes it very visible when overrides are active, so it won't silently affect production behavior.

[meta-codesync]

@Prashasthi-Ranjan has imported this pull request. If you are a Meta employee, you can view this in D105119384.