Yarp is greatly affected by downstream services

### Describe the bug

When the response time of the downstream service of the reverse-proxy service fluctuates, the CPU fluctuation is very obvious

### To Reproduce

[Downstream.zip](https://github.com/user-attachments/files/16749229/Downstream.zip)
1. Deploy Downstream on a Windows machine
2. Deploy the reverse-proxy service on the Linux server, and point the proxy address to the Downstream service on the Windows machine.
3. Use hey or other stress testing tools to stress test the reverse-proxy service according to the specified qps
4. By changing the sleep time of Downstream, check the CPU fluctuation of reverse-proxy service.

Reproduce the problem
It is found that the service where reverse-proxy is located is greatly affected by the downstream. When the downstream service responds slowly, the QPS of the reverse-proxy service will decrease, and the corresponding requests being processed will increase. When the downstream service returns to normal, the CPU of the reverse-proxy service increases rapidly. In other words, the reverse-proxy service is greatly affected by the downstream. I hope that the CPU can be more stable, even if the CPU is occupied in advance, the same principle applies to threads. I don’t want the CPU to surge or plummet when there is a burst of traffic, because the response time of the downstream service is completely uncontrollable. How to deal with this problem?

### Further technical details

- Include the version of the packages you are using
- Downstream
- deploy Windows System
- .net version: .net 8.0
- reverse-proxy
- deplpy Linux System
- .net version: .net 9.0