…e tests

This makes the Transport ignore 100-continue responses from servers,
rather than get confused by them. This is good enough for
golang/go#13659. I filed golang/go#13851 to do better later, but
that's less important.

This CL also adds comprehensive tests for the 36 different ways that
frames can be arranged from servers when reading a response. That
exposed some bugs (now fixed), and even affected the http2 API: I'd
added a END_STREAM accessor on CONTINUATION frames, but it's not even
valid there.

I also renamed some confusing variables which sounded too similar.

Updates golang/go#13659
Updates golang/go#13851

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

For now, don't enable http2 when Transport.TLSConfig != nil.
See background in #14275.

Also don't enable http2 when ExpectContinueTimeout is specified for
now, in case somebody depends on that functionality. (It is not yet
implemented in http2, and was only just added to net/http too in Go
1.6, so nobody would be setting it yet).

Updates #14275
Updates #13851

Change-Id: I192d555f5fb0a567bd89b6ad87175bbdd7891ae3
Reviewed-on: https://go-review.googlesource.com/19424
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

In Go 1.6, the HTTP/1 client got Transport.ExpectContinueTimeout.

This makes the HTTP/2 client respect a Request's "Expect:
100-continue" field and the Transport.ExpectContinueTimeout
configuration.

This also makes sure to call the traceWroteRequest hook if the server
replied while we're still writing the request, since that code was
in the same spot and it couldn't be trivially separated.

Updates golang/go#13851 (fixed after integrating it into std)
Updates golang/go#15744

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