[test] Fix flaky FlexCounter.bulkChunksize under AddressSanitizer

[rustiqly]

Description

Fix the FlexCounter.bulkChunksize unit test that fails intermittently under AddressSanitizer (Asan) builds.

Root Cause

Under Asan, the test thread runs 2-5x slower while the FlexCounter worker thread polls at its normal 1000ms interval. This creates a race condition:

1. Test creates FlexCounter with status=enable and poll_interval=1000
2. Test adds 6 port counters one by one
3. FlexCounter worker starts polling — but under Asan, only 1 port may be registered
4. Test sets BULK_CHUNK_SIZE=3 — but the worker already consumed initialCheckCount

Result: mock_bulkGetStats receives object_count=1 when expecting 3, causing:

TestFlexCounter.cpp:1581: Failure
Expected equality of these values:
  object_count
    Which is: 1
  3

This failure is 100% reproducible on the BuildAsan CI pipeline.

Fix

Added an std::atomic<bool> chunkConfigReady flag to synchronize the test thread and FlexCounter worker:

• In mock_bulkGetStats: after the initialCheckCount guard, if chunkConfigReady is false, treat the call as an extra initialization poll — populate counters but skip chunk-size assertions
• In testAddRemoveCounter: added an optional onChunkConfigApplied callback parameter that fires after chunk config is applied to the FlexCounter
• Per test case: flag is reset to false before calls where bulkChunkSizeAfterPort=true (config applied after ports → race possible), and pre-set to true for bulkChunkSizeAfterPort=false or forceSingleCall=true cases (no race)

This eliminates the timing dependency entirely — no sleeps, no increased timeouts, just explicit synchronization via atomic flag.

Testing

• Verified the fix compiles and the test logic is correct
• The previous fix approach (PR [test] Fix flaky FlexCounter.bulkChunksize by replacing usleep with poll-wait #1766, poll-wait) solved the normal build flakiness but didn't handle the Asan case where overhead is much larger

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[Copilot]

Pull request overview

Fixes a timing-dependent race in the FlexCounter.bulkChunksize unit test that becomes consistently reproducible under AddressSanitizer, by explicitly synchronizing the test thread with the FlexCounter polling thread.

Changes:

• Add an atomic readiness flag used by the bulk stats mock to skip chunk-size assertions until chunk-size configuration is applied.
• Extend testAddRemoveCounter with an optional callback to signal when chunk configuration has been applied.
• Update FlexCounter.bulkChunksize test scenarios to set/reset the readiness flag appropriately depending on configuration order.

[Copilot]

The counter-population logic in the !chunkConfigReady guard duplicates the runtime loop below (same per-object/per-counter map update + counter fill). Consider extracting that shared logic into a small local helper/lambda to keep the mock consistent and reduce maintenance risk if the generation logic changes later.

[Copilot]

testAddRemoveCounter is accumulating many positional parameters (now including onChunkConfigApplied), which makes call sites hard to read and easy to mis-order. Consider grouping the bulk/chunk configuration flags into a small options struct (or splitting into a few targeted helpers/overloads) so the bulkChunksize test can pass clearly named settings without a long argument list.