When not buffering, flushing should cause `Response.End()` to be called

[twsouthwick]

Repro

Response.HttpContext.Features.GetRequired<IHttpResponseBufferingFeature>().DisableBuffering();
...
// The response will be sent to client after this line
// Let's say current at `RequestNotification.ExecuteRequestHandler`
Reponse.Body.Write(....);

// But the rest of events will still be raised, like
// `RequestNotification.ReleaseRequestState` and so on.

Expected behavior

Please consider to raise IHttpResponseEndFeature.EndAsync() or proper method together to align framework.
https://github.com/microsoft/referencesource/blob/51cf7850defa8a17d815b4700b67116e3fa283c2/System.Web/HttpWriter.cs#L1610

Originally posted by @TaoziZ03 in #509 (comment)

[twsouthwick]

When I run it on framework, those events are still raised:

BeginRequest
PreSendRequestHeaders
AuthenticateRequest
PostAuthenticateRequest
AuthorizeRequest
PostAuthorizeRequest
ResolveRequestCache
PostResolveRequestCache
MapRequestHandler
PostMapRequestHandler
AcquireRequestState
PostAcquireRequestState
PreRequestHandlerExecute
Hello world
PostRequestHandlerExecute
ReleaseRequestState
PostReleaseRequestState
UpdateRequestCache
PostUpdateRequestCache
LogRequest
PostLogRequest
EndRequest

Note the headers are sent early (and the content event isn't enabled in the pr you raised the issue on). Once everything is merged, we can see if it still repros.

@TaoziZ03 can you provide a working sample of what you're seeing on framework?

[TaoziZ03]

I tested locally with all related changes. Pinged you offline about the repro.

It runs into native codes and raises the SendResponse event directly. Here is the stack trace.

[TaoziZ03]

I did some further tests. Turns out the existing app doesn't register events after the post execute handler. I can verify the behavior is equal if all the events are registered. Sorry for the incorrect issue. Please close this one. Thanks!

[twsouthwick]

oh great! thanks for the follow up