Skip CooperativeBlockingCanCreateThreadsFaster on Debug runtimes

[Copilot]

ThreadPoolTests.CooperativeBlockingCanCreateThreadsFaster is timing-sensitive and has been failing intermittently in CI. Every observed failure was in a Debug configuration, where the runtime is slow enough that the test's timing assumptions no longer hold — consistent with the historical investigation in #66765, which attributed failures to timeouts under concurrent load.

Changes

• Added IsThreadingAndRemoteExecutorSupportedAndNotDebugRuntime to ThreadPoolTests, combining the existing condition with !PlatformDetection.IsDebugRuntime.
• Switched the ConditionalFact on CooperativeBlockingCanCreateThreadsFaster to use it, so the test still runs in Release/Checked and is skipped on Debug.

// Timing-sensitive tests can be too flaky on a Debug runtime, which is much slower
public static bool IsThreadingAndRemoteExecutorSupportedAndNotDebugRuntime =>
    IsThreadingAndRemoteExecutorSupported && !PlatformDetection.IsDebugRuntime;

Test-only change; no product code is affected.

• Fixes ThreadPoolTests.CooperativeBlockingCanCreateThreadsFaster failed on 10.0 on Windows #129976

[Copilot]

Copilot wasn't able to review any files in this pull request.

[azure-pipelines]

Azure Pipelines:
16 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.

Suppressed comments (1)

src/libraries/System.Threading.ThreadPool/tests/ThreadPoolTests.cs:1506

• PlatformDetection already provides SlowRuntimeTimeoutModifier specifically for tests that time out on Debug/Checked runtimes (see PlatformDetection.SlowRuntimeTimeoutModifier). Skipping the test entirely on Debug reduces coverage and may mask debug-only issues; consider instead scaling the WaitOne timeout by SlowRuntimeTimeoutModifier (or otherwise using that helper) so the test can still run on slower runtimes, unless there’s a strong reason to avoid lengthening Debug CI runs.

        // Timing-sensitive tests can be too flaky on a Debug runtime, which is much slower
        public static bool IsThreadingAndRemoteExecutorSupportedAndNotDebugRuntime =>
            IsThreadingAndRemoteExecutorSupported && !PlatformDetection.IsDebugRuntime;

[VSadov]

@eduardo-vp - a test only change blocking a test on Debug corelib.

I do not think the PR will fail, since the failure is fairly rare. We can merge and see if it still reproduces.

[dotnet-policy-service]

Tagging subscribers to this area: @JulieLeeMSFT, @VSadov
See info in area-owners.md if you want to be subscribed.

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
13 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.