Fix race conditions in updating RemoteTaskStats

[raunaqmorarka]

Description

In the existing implementation, the shared currentRequestStartNanos object
may be updated by the next request after the current request future is done
but before the callback handler has read the value of currentRequestStartNanos
set before the current request was started.

General information

Is this change a fix, improvement, new feature, refactoring, or other?

Fix

Is this a change to the core query engine, a connector, client library, or the SPI interfaces? (be specific)

Core query engine

How would you describe this change to a non-technical end user or system administrator?

Fixes potential inaccuracies in recording of RemoteTaskStats

Related issues, pull requests, and links

Documentation

(x) No documentation is needed.
( ) Sufficient documentation is included in this PR.
( ) Documentation PR is available with #prnumber.
( ) Documentation issue #issuenumber is filed, and can be handled later.

Release notes

(x) No release notes entries required.
( ) Release notes entries required with the following suggested text:

[findepi]

@raunaqmorarka is this related to #11039 ?

[raunaqmorarka]

@findepi I don't think this will resolve the value is negative failures. It's just going to avoid inaccuracies in stats due to a possible race condition.

[arhimondr]

From what I understand ContinuousTaskStatusFetcher wasn't susceptible to this issue as a new request is always scheduled from a callback, but DynamicFiltersFetcher and TaskInfoFetcher were

[losipiuk]

Merged, thanks!