runtime: fix build on openbsd/386

R=golang-dev, minux.ma, r
CC=golang-dev
https://codereview.appspot.com/8569043

Committer: Rob Pike <r@golang.org>
cmd/ld: ignore PE sections that are not code or data

Update issue 5106
Update issue 5273

R=minux.ma, r
CC=golang-dev
https://codereview.appspot.com/8715043
test/stress: start of a runtime stress program

Runs forever, stressing the runtime in various ways.

It should never terminate.

R=golang-dev, r, minux.ma
CC=golang-dev
https://codereview.appspot.com/8583047
net/http/cookiejar: mention go.net/publicsuffix.

R=golang-dev, r, gary.burd, dr.volker.dobler
CC=golang-dev
https://codereview.appspot.com/8660046
doc/reference.html: update list of sub-repositories.

R=golang-dev, bradfitz, r
CC=golang-dev
https://codereview.appspot.com/8766043
database/sql: close driver Stmt before releasing Conn

From the issue, which describes it as well as I could:

database/sql assumes that driver.Stmt.Close does not need the
connection.

see database/sql/sql.go:1308:

This puts the Rows' connection back into the idle pool, and
then calls the driver.Stmt.Close method of the Stmt it belongs
to.  In the postgresql driver implementation
(https://github.com/lib/pq), Stmt.Close communicates with the
server (on the connection that was just put back into the idle
pool).  Most of the time, this causes no problems, but if
another goroutine makes a query at the right (wrong?) time,
chaos results.

In any case, traffic is being sent on "free" connections
shortly after they are freed, leading to race conditions that
kill the driver code.

Fixes Issue 5283

R=golang-dev, r
CC=golang-dev
https://codereview.appspot.com/8633044