Add support for non buffered body server responses.

[pablolagos]

Adds support for non-buffered responses.

Sometimes we want to respond by copying from a stream (files or remote network connections), but the current method RegisterStreamBody has 2 cons:

• Is executed after the handler function returns
• Create 2 go threads and 2 channels for each response

This feature allows us to stream directly from the handler context

In server

´func handle(ctx *fasthttp.RequestCtx) {
     // DisableBuffering modifies fasthttp to disable headers and body buffering for this request
     ctx.DisableBuffering()
     
     // Write headers
     ctx.Response.Header.Set(.....)
     ctx.Response.Header.Set(.....)
     ctx.Response.Header.Set(.....)
     ctx.SetStatusCode(StatusOK)
    
     // Write body. Headers will be sent and cannot be modified once the body begins to be dispatched.
     // src can be any io.Reader or io.ReaderFrom or any object implementing io.WriteTo
     // The process would be unbuffered, well, actually using at most a 32KB buffer 
     // according to the current io.Copy implementation.
     // Ideal for serving large files without storing them on RAM. 
     io.Copy(ctx, src)

     // Optionally we can call CLoseReponse() or it will be called automatically after handler returns
     ctx.CloseResponse()

     fmt.Printf("Total bytes sent including headers: %d",ctx.BytesSent())
}

It will automatically set the Transfer-Encoding header to "chunked" and chunk the content on the fly.

[pablolagos]

Fixed test. I included a check in the server as you suggested.

[pablolagos]

I changed the approach maintaining the original idea in the API usage.

The reason for this change is to support the use of protocols other than HTTP/1.x and to allow compatibility with the packages that provide them (dgrr/http2, for example).

If this PR is merged into the code base, I will make the necessary modifications to dgrr/http2.

[erikdubbelboer]

Why add this function?

[pablolagos]

After streaming a response, it can be necessary to know the number of bytes sent. That number is known only if we a serving local resources, but unknown if we are proxying from external sources. Bytes sent can represent a cost related to data-transfer. It can be useful for logging and other analysis.

We could return that value in ctx.CloseReponse()

[erikdubbelboer]

For now I would remove this. This isn't supported with normal responses either so it's weird to only add it for this case now.

[erikdubbelboer]

I don't think this type should be exposed, it can be kept internally. I also wouldn't add Http1 to the name as everything in fastthttp is http1.

[erikdubbelboer]

This function can also be kept internal then.

[erikdubbelboer]

Make it something like use of closed unbuffered writer

[erikdubbelboer]

I don't think this state needs to be kept here, you can just add a headersWritten bool to UnbufferedWriterHttp1.

[erikdubbelboer]

Probably faster and more efficient to use uw.ctx.Response.Header.WriteTo(uw.writer)

[erikdubbelboer]

Can you add a test to make sure this works, calling CloseResponse() without writing anything to the body.