Use async ChangeToken.OnChange overload in FileConfigurationProvider

[svick]

Uses the new async (Func<Task>) overload of ChangeToken.OnChange (see #69099) in FileConfigurationProvider.

The reload callback previously blocked a thread for the whole reload delay via Thread.Sleep(Source.ReloadDelay). It now awaits Task.Delay(...) instead, so no thread is blocked while waiting out the debounce delay before reloading:

_changeTokenRegistration = ChangeToken.OnChange(
    () => Source.FileProvider.Watch(Source.Path!),
    async () =>
    {
        await Task.Delay(Source.ReloadDelay).ConfigureAwait(false);
        Load(reload: true);
    });

Why only this call site

The other in-repo callers of ChangeToken.OnChange (ConfigurationRoot, ConfigurationManager, OptionsMonitor) invoke short, synchronous, non-blocking consumers (RaiseChanged / InvokeChanged) and gain nothing from the async overload, so they are intentionally left unchanged.

A closely related change is at dotnet/aspnetcore#67732.

Note

This PR description was generated by GitHub Copilot.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-extensions-configuration
See info in area-owners.md if you want to be subscribed.

[Copilot]

Pull request overview

This PR updates FileConfigurationProvider’s file-change reload callback to use the async ChangeToken.OnChange overload and replace a blocking Thread.Sleep debounce with an awaited Task.Delay, aiming to avoid tying up a thread during the reload delay.

Changes:

• Replace Thread.Sleep(Source.ReloadDelay) with await Task.Delay(Source.ReloadDelay).ConfigureAwait(false) inside the reload callback.
• Switch the callback passed to ChangeToken.OnChange to an async lambda (binding to the Func<Task> overload).
• Update using directives accordingly (System.Threading → System.Threading.Tasks).

[svick]

In the synchronous case, the exception is rethrown in whatever the IFileProvider uses for watching. In case it's PhysicalFilesWatcher, the exception is swallowed anyway.

So I don't think this is a problem.

[tarekgh]

It holds specifically for PhysicalFilesWatcher (the provider behind  AddJsonFile / AddXmlFile  etc.). A hypothetical custom IFileProvider that invokes token callbacks synchronously and lets exceptions propagate would surface the error in the sync model but not the async one. That is within the async overload's documented contract ("asynchronous exceptions are left unobserved"). I know this is minor issue but is it possible?