Fix race conditions in aggregate ProfileFileSupplier

[alextwoods]

Fix race conditions in aggregate ProfileFileSupplier.

Motivation and Context

This change fixes multiple race conditions in the aggregate ProfileFileSupplier. #6632 re-introduced profile file reloading which exposed these issues, resulting in credentials resolution failure if a shared DefaultCredentialsProvider instance with a profile name configured is used across multiple threads.

The most series issues is that get() determines whether to recompute the aggregate based on a snapshot of currentValuesBySupplier, but refreshCurrentAggregate() then reads a different snapshot of that same map — and nothing prevents another thread from mutating it in between. The AtomicReference and synchronizedMap give us local thread safety, but not atomicity across the whole operation.

Modifications

• Use a single atomic state that captures both elements and ensure that its updated consistently.

Testing

Added a new unit test + manual testing.

Screenshots (if appropriate)

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)

Checklist

• I have read the CONTRIBUTING document
• Local run of mvn install succeeds
• My code follows the code style of this project
• My change requires a change to the Javadoc documentation
• I have updated the Javadoc documentation accordingly
• I have added tests to cover my changes
• All new and existing tests passed
• I have added a changelog entry. Adding a new entry must be accomplished by running the scripts/new-change script and following the instructions. Commit the new file created by the script in .changes/next-release with your changes.
• My change is to implement 1.11 parity feature and I have updated LaunchChangelog

License

• I confirm that this pull request can be released under the Apache 2 license

[dagnir]

Trying to reason about this. If the state got updated in between, do we actually need to retry here? Assuming that earlier update is also valid.

[alextwoods]

I think its actually a reasonable assumption to just return whatever the updated state is in this case - which lets us remove the while(true) which is good.

I'm working on benchmarking for this + another optimization that removes the new map creation in most cases.

[sonarqubecloud]

Quality Gate passed

Issues
3 New issues
0 Accepted issues

Measures
0 Security Hotspots
96.2% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[github-actions]

This pull request has been closed and the conversation has been locked. Comments on closed PRs are hard for our team to see. If you need more assistance, please open a new issue that references this one.