Fix race condition in ConfigurationManager refresh state (#3142)

[dipeshchaudhari3255]

Fix race condition in ConfigurationManager refresh state (#3142)

• You've read the Contributor Guide and Code of Conduct.
• You've included unit or integration tests for your change, where applicable.
• You've included inline docs for your change, where applicable.
• If any gains or losses in performance are possible, you've included benchmarks for your changes.
• There's an open issue for the PR that you are making.

Summary of the changes

Fix race condition caused by non-atomic refresh timestamp access.

Description

Issue #3142 reports a thread-safety concern around concurrent access to refresh timing state in ConfigurationManager.

The fields _syncAfter and _lastRequestRefresh were used by multiple threads to determine whether a configuration refresh was required. These values were accessed concurrently without atomic read/write operations, which could result in inconsistent observations under heavy concurrency and lead to duplicate metadata retrievals.

Changes

• Store _syncAfter as long ticks.
• Store _lastRequestRefresh as long ticks.
• Replace direct reads with Interlocked.Read.
• Replace direct writes with Interlocked.Exchange.
• Add inline comments documenting the thread-safety rationale and the relationship to Issue [Bug] Ensure updates to state are done atomically in ConfigurationManager #3142.

Validation

The issue was reproduced using a test application that generated 50 concurrent refresh requests.

Before the fix:

• Request count: 50
• Actual metadata HTTP calls: 2

After the fix:

• Request count: 50
• Actual metadata HTTP calls: 1

This confirms that concurrent refresh requests no longer trigger multiple simultaneous metadata retrievals.

Fixes #3142