The Transport's automatic gzip uncompression lost information in the
process (the compressed Content-Length, if known). Normally that's
okay, but it's not okay for reverse proxies which have to be able to
generate a valid HTTP response from the Transport's provided
*Response.

Reverse proxies should normally be disabling compression anyway and
just piping the compressed pipes though and not wasting CPU cycles
decompressing them. So also document that on the new Uncompressed
field.

Then, using the new field, fix Response.Write to not inject a bogus
"Connection: close" header when it doesn't see a transfer encoding or
content-length.

Updates #15366 (the http2 side remains, once this is submitted)

Change-Id: I476f40aa14cfa7aa7b3bf99021bebba4639f9640
Reviewed-on: https://go-review.googlesource.com/22671
Reviewed-by: Andrew Gerrand <adg@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Go 1.7 introduces Request.Context and Response.Uncompressed. Use them
both in the http2 Transport when building for Go 1.7.

Tests are in the main repo.

Updates golang/go#15366
Updates golang/go#15134

Change-Id: I4b78a2710b6cf30c769c7f85cea15ecde653a317
Reviewed-on: https://go-review.googlesource.com/23002
Reviewed-by: Andrew Gerrand <adg@golang.org>