Fix timing race in BackpressureTimeout_must_succeed_if_subscriber_demand_arrives test

[Aaronontheweb]

Summary

Fixed an intermittent test failure in BackpressureTimeout_must_succeed_if_subscriber_demand_arrives that was occurring in CI/CD environments due to timing race conditions.

Root Cause

The test was experiencing a timing race where accumulated delays exceeded the backpressure timeout threshold:

• Original timeout: 1 second
• Accumulated delays: 3 iterations × 250ms = 750ms
• Safety margin: Only 250ms

In CI/CD environments with thread pool contention, async/await overhead, and timer imprecision, this insufficient margin caused the timeout to trigger before demand was registered, resulting in:

Expected OnNext(int), but received OnError("No demand signalled in the last 00:00:01.")

Changes

• Increased BackpressureTimeout from 1 second to 2 seconds
• Reduced ExpectNoMsg delays from 250ms to 100ms per iteration

Result

• New timeout: 2000ms
• New accumulated delays: 3 × 100ms = 300ms
• New safety margin: 1700ms (5.7× improvement)

This provides adequate buffer for:

• Async/await scheduling overhead
• Test infrastructure processing delays
• CI/CD thread pool contention and resource constraints
• Timer check granularity (250ms intervals for 2-second timeout)

Testing

✅ Test passes reliably with the new timing parameters
✅ Test semantics unchanged - still verifies demand arriving within timeout prevents backpressure errors

Related

Addresses racy test failures similar to other timeout tests in the same file that are marked as LocalFact.

[Aaronontheweb]

This is, unfortunately, a timing-sensitive test and timeout jiggling is probably the best solution here