Implement response BodyWriter, CompleteAsync for TestServer

[Tratcher]

gRPC depends on pipes and a few other features only implemented by Kestrel such as StartAsync and CompleteAsync. Missing those features in TestServer makes it hard to test gRPC and related components.

• BodyWriter
• Reset (HTTP2)
• StartAsync
• CompleteAsync

TestServer already uses a pipe internally for its response data, but exposing it turns out to be complicated because we add lots of semantics on top such as the first flush sending headers, content-length verification, etc..

#11305
#11194

@JamesNK

[Tornhoof]

May I ask why it is hard to test, does gRPC not work with the TestServer?

I'm asking for my HttpBatchHandler middleware, which is very similar to the TestServer from ASP.NET Core 2.x, it still works in 3.0 (atleast the current tests do), but I'm not sure if I want to add the Pipe complexity to my middleware, so it would be nice to know which features might rely on new RequestFeature/ResponseFeature functionality (like that IHttpResponseCompletionFeature.CompleteAsync thing).

[JamesNK]

I've just changed gRPC integration tests to use Kestrel instead of test server. HTTP/2 support in HttpClient is rather hot and I wanted more testing with it and gRPC.

grpc/grpc-dotnet#349

These TestServer improves are Good, but they don't need to be a priority because of gRPC.

[Tratcher]

FYI running too many network tests can cause things like socket exhaustion, especially on Mac. Yes we need integration tests with HttpClient, but most unit tests should use TestServer or similar mocks.

[Tratcher]

Note to self, Abort was only half implemented. It would fire RequestAborted, but not surface any errors to the client.