Add secondary poll factor to flex counter infra

[apoorv-arista]

HLD Link : fec-flr-hld

What I did

Added a secondary poll factor feature to the flex counter infrastructure. This enhancement introduces a new secondary_poll_factor parameter that allows dynamic adjustment of polling intervals for specific counter types. The implementation includes:

• Modified FlexCounter class to support secondary poll factor configuration
• Updated Redis remote SAI interface to handle the new parameter
• Enhanced counter polling logic to apply secondary poll factor when configured
• Maintained backward compatibility when secondary poll factor is not specified

Why I did it

To provide more granular control over counter polling intervals, especially for FEC FLR (Forward Error Correction Frame Loss Rate) counters. This feature allows:

• Different polling frequencies for performance-critical counters
• Optimized resource utilization by adjusting poll rates based on counter importance
• Better monitoring capabilities for specific counter types that require different sampling rates
• Reduced system overhead by allowing less frequent polling for non-critical counters while maintaining high-frequency polling for critical ones

How I verified it

• Verified that secondary poll factor correctly modifies polling intervals when configured
• Ensured backward compatibility - existing behavior is preserved when secondary poll factor is not configured
• Tested with FEC FLR counters to validate the intended use case
• Verified the feature through manual testing with different poll factor values
• Confirmed proper integration with the Redis database layer

Details if related

• This feature is particularly useful for monitoring FEC FLR counters which may require different polling frequencies than other counter types
• The secondary poll factor is applied as a multiplier to the base polling interval
• When not configured, the system defaults to the primary polling interval, ensuring no impact on existing deployments
• Related to performance optimization efforts for counter collection in high-scale environments

Build Order Requirements

┌──────────────────────────────┐
│  sonic-swss-common (#1110)   │  ◄── Foundation (no dependencies)
└──────────────────────────────┘
         │                  
         │                  
         ├──────────────────────────┐
         │                          │
         │                          │
         v                          │
┌──────────────────────────────┐    │
│  sonic-sairedis (#1699)      │    │
│  depends on:                 │    │
│    - sonic-swss-common       │    │
└──────────────────────────────┘    │
         │                          │
         │                          │
         └──────────┬───────────────┘
                    │
                    v
         ┌──────────────────────────────┐
         │  sonic-swss (#4002)          │
         │  depends on:                 │
         │    - sonic-sairedis          │
         │    - sonic-swss-common       │
         └──────────────────────────────┘

Build Order (bottom-up):
sonic-swss-common (#1110) - build first
sonic-sairedis (#1699) - build second
sonic-swss (#4002) - build last
PR Merge Order: The PRs should be merged in the same order: #1110 → #1699 → #4002

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[apoorv-arista]

The build pipelines for this PR are failing because they have interdependent changes.

I have updated the PR description with build order requirements