Remove flaky HttpSys test Server_MultipleOutstandingSyncRequests_Success

[Tratcher]

https://github.com/aspnet/AspNetCore-Internal/issues/2415
Since switching to Arcade this has become the second flakiest test.
https://dev.azure.com/dnceng/public/_test/analytics?definitionId=278&contextType=build
It's intentionally trying to test sync thread blocking, but that makes it extremely vulnerable to thread pool starvation that we've experienced elsewhere in our tests. Even leaving the test here marked as flaky has a negative impact on other tests.

This test has limited value so I'm removing it.

[halter73]

Could we move tests that need to block a bunch of threads to their own test group that doesn't run tests in parallel. Deleting every test that blocks a lot of threads doesn't seem sustainable. Sometimes tests simply have to block multiple threads to test a certain behavior.

I get that Server_MultipleOutstandingSyncRequests_Success might have "limited value", but I what about other tests that spawn several threads like Kestrel's ListenerPrimaryTests? Then it can be a tougher decision to delete the test. If we had a special test group to add it to, that'd be great.

Also, can you explain why this test is of limited value?

[Tratcher]

This test existed only to prove that the message pump used multiple threads and that it would keep going even if the app blocked threads. But what we're seeing now is that the server really can't handle threadpool exhaustion so there's no point in testing that it can. There's an async version of this test that works fine.

[halter73]

But what we're seeing now is that the server really can't handle threadpool exhaustion so there's no point in testing that it can.

I don't think this is a reason to stop testing that our servers can support at least a small number of blocked request threads. A lot of real customer apps block, and it often isn't too much of a problem as long as there isn't too much load.

[davidfowl]

I think the test is fine to delete