Update copy logic to use dedicated threads.

[Erarndt]

Also updated some checks to help avoid hitting the file system if possible.

Fixes #

Context

The existing implementation does synchronous file copying on threadpool threads which can lead to starvation. Switching to dedicated threads to do synchronous copying helps keep the threadpool threads available for other tasks.

Changes Made

Testing

Notes

[rainersigwald]

Just kinda generally, I'm surprised to hear about threadpool starvation in our worker nodes which aren't threadpool heavy. Have you observed this in practice?

[Erarndt]

Just kinda generally, I'm surprised to hear about threadpool starvation in our worker nodes which aren't threadpool heavy. Have you observed this in practice?

There is some sneaky utilization of the threadpool that ends up blocking enough to see the "hill climbing" algorithm start spinning up new threads. I've seen between 40 and 50 threadpool threads per MSBuild processes which is over 3x what I would expect. This change (#11275) has a larger impact than the copy code, but this contributes as well. There's also additional benefit to reducing the mix of I/O bound work and CPU bound work on the threadpool.

[JanKrivanek]

Related to #11160