Deflake Kestrel low response rate tests

[halter73]

After the netcoreapp3.0 to netcoreapp5.0 dependency update yesterday. Kestrel's ConnectionNotClosedWhenClientSatisfiesMinimumDataRateGivenLargeResponseChunks/Headers tests have become very, very flaky on Linux.

I'm not exactly sure what in the dependency update induced this flakiness (I assume it's some change to System.Net.Sockets), but my guess is that doing a "Connection: close" response where Kestrel disposes the socket immediately after writing the final response body while the client is reading the response at a very low rate is part of the problem leading the connection resets reported by the client.

To fix this, we might want to consider addressing #13219 which would mean waiting for a FIN from the client (with some timeout) before fully closing the socket.

Since the now-flaky tests were intended to verify that Kestrel didn't abort the request because of MinOutputDataRate timeout, I rewrote the tests to use a keep-alive connection instead.

I then added a new test which I pre-marked as flaky on Linux and Helix which verifies that "Connection: close" responses can be read at a low rate.

[jkotalik]

I'm fairly certain dotnet/corefx#38804 caused this regression. Will follow up with CoreFx.