An optimization in Transport which re-uses TCP
connections early in the case where there is
no response body interacted poorly with
ErrBodyReadAfterClose.  Upon recycling the TCP
connection early we would Close the Response.Body
(in case the user forgot to), but in the case
of a zero-lengthed body, the user's handler might
not have run yet.

This CL makes sure the Transport doesn't try
to Close requests when we're about to immediately
re-use the TCP connection.

This also includes additional tests I wrote
while debugging.

R=rsc, bradfitzgoog
CC=golang-dev
https://golang.org/cl/4529050

R=r
CC=golang-dev
https://golang.org/cl/4521054

R=r
CC=golang-dev
https://golang.org/cl/4523054

Fixes #1796.

R=rsc, r2, niemeyer
CC=golang-dev
https://golang.org/cl/4539049

crl parses CRLs and exposes their details. In the future, Verify
should be able to use this for revocation checking.

R=bradfitz
CC=golang-dev
https://golang.org/cl/4485045

issue 1604

R=rsc, bradfitz
CC=golang-dev
https://golang.org/cl/4313062

R=adg, rsc, kevlar, r
CC=golang-dev
https://golang.org/cl/4476045

R=rsc, dsymonds
CC=golang-dev
https://golang.org/cl/4528053

Fixes #1608.
Fixes #1787.

R=ken2
CC=golang-dev
https://golang.org/cl/4530045

So far, only top-level names where considered when trimming ASTs
using a filter function. For instance, "godoc reflect Implements"
didn't show the "Implements" method of the type Interface because
the local method name was not considered (on the other hand, "top-
level" declared methods associated with types were considered).

With this CL, AST filter functions look also at struct fields
and interface methods.

R=rsc, r
CC=golang-dev
https://golang.org/cl/4518050

R=rsc, bradfitz
CC=golang-dev
https://golang.org/cl/4523047

writing the idct result directly to the image buffer instead of
storing it in an intermediate d.blocks field.

Writing to d.blocks was necessary when decoding to an image.RGBA image,
but now that we decode to a ycbcr.YCbCr we can write each component
directly to the image buffer.

Crude "time ./6.out" scores to decode a specific 2592x1944 JPEG 20
times show a 16% speed-up:

BEFORE

user	0m10.410s
user	0m10.400s
user	0m10.480s
user	0m10.480s
user	0m10.460s

AFTER

user	0m9.050s
user	0m9.050s
user	0m9.050s
user	0m9.070s
user	0m9.020s

R=r
CC=golang-dev
https://golang.org/cl/4523052

gofmt -w src misc

Fixes #1414.

R=rsc, r
CC=golang-dev
https://golang.org/cl/4456054

When traversing parameter lists (e.g. for type checking), we want the
invariant that all identifers have associated objects (even _ idents),
so that we can associate a type with each object.

R=rsc
CC=golang-dev
https://golang.org/cl/4490042

Had bit test wrong on transparency; no excuses.

R=nigeltao
CC=golang-dev
https://golang.org/cl/4526044

At least, as I understand it. The spec is unclear about what happens
with a local color map.

R=nigeltao, r2
CC=golang-dev
https://golang.org/cl/4515045

Fixes #1786.

R=gri, adg
CC=golang-dev
https://golang.org/cl/4517043

Fixes #1788.

R=rsc, adg
CC=golang-dev
https://golang.org/cl/4519042

R=golang-dev, r, r2
CC=golang-dev
https://golang.org/cl/4471046

This change fixes generation of "shadow" variables for bool parameters.
Before the change, it was naming all bool variables with the same name of _p0.
Now it calls them _p0, _p1, ... So the code could compile.

R=golang-dev, r
CC=golang-dev
https://golang.org/cl/4479047

It's incomplete but sufficient to decode 8-bit GIFs without interlacing
or transparency.   More to come.

I'll put in more tests as the feature set grows.

R=nigeltao, r2
CC=golang-dev
https://golang.org/cl/4522041

instead of returning an error.

For example, http://www.w3.org/Graphics/GIF/spec-gif89a.txt
explicitly says that GIF encoders can use a full table as is,
without needing to send a clear code.

R=r, dsymonds, nigeltao_gnome, r2
CC=golang-dev
https://golang.org/cl/4518041

Fixes #1785.

R=golang-dev, dsymonds
CC=golang-dev
https://golang.org/cl/4496042

R=golang-dev, r
CC=golang-dev
https://golang.org/cl/4492043

This means that the -x flag can work, which could enable
support for other languages (e.g. objective-C).

R=iant, rsc
CC=golang-dev
https://golang.org/cl/4476049

R=adg, rsc1, rsc
CC=golang-dev
https://golang.org/cl/4491041

R=rsc
CC=golang-dev
https://golang.org/cl/4396050

R=adg
CC=golang-dev
https://golang.org/cl/4485046

R=golang-dev, r
CC=golang-dev
https://golang.org/cl/4477046

The verified chains are the chains that were actually verified.

R=bradfitz
CC=golang-dev
https://golang.org/cl/4462046

The SPKI will probably be used for identifying public keys in future
HSTS specs.

R=bradfitz
CC=golang-dev
https://golang.org/cl/4485044

R=nigeltao, r
CC=golang-dev
https://golang.org/cl/4471045

R=r
CC=golang-dev
https://golang.org/cl/4462043

The current iteration can decode 8-bit images in
grayscale, paletted, RGB, RGBA and NRGBA mode. LZW compression
is implemented but does not work on my test images.
Deflate (i.e. zlib) compression with or without a horizontal
predictor is supported.

R=nigeltao, nigeltao_gnome
CC=golang-dev, mpl
https://golang.org/cl/4240051

Encoder now writes tRNS chunk for non-opaque paletted images.
CL includes new test images (basn3a08-trns.[ps]ng).

R=nigeltao, rsc, r
CC=golang-dev
https://golang.org/cl/4432078

R=rsc, bradfitz
CC=golang-dev
https://golang.org/cl/4436074

On my laptop, I had an 800x600 jpeg and an 800x600 png (with
transparency). I timed how long it took to draw each image onto an
equivalently sized, zeroed RGBA image.

Previously, the jpeg took 75ms and the png took 70ms, going through
the medium-fast path, i.e. func drawRGBA in draw.go.

After this CL, the jpeg took 14ms, and the png took 21ms with the
Over operator and 12ms with the Src operator.

It's only a rough estimate basd on one image file, but it should
give an idea of the order of magnitude of improvement.

R=rsc, r
CC=adg, golang-dev
https://golang.org/cl/4468044

R=adg
CC=golang-dev
https://golang.org/cl/4468043

R=adg
CC=golang-dev
https://golang.org/cl/4471041

R=rsc
CC=golang-dev
https://golang.org/cl/4463042