net/http: TestContentTypeWithVariousSources failures

[gopherbot]

#!watchflakes
post <- pkg == "net/http" && test == "TestContentTypeWithVariousSources" && `timeout waiting for .* frames`

Issue created automatically to collect these failures.

Example (log):

--- FAIL: TestContentTypeWithVariousSources (0.00s)
    --- FAIL: TestContentTypeWithVariousSources/h2 (5.52s)
        --- FAIL: TestContentTypeWithVariousSources/h2/write_one_byte_at_a_time (3.25s)
            clientserver_test.go:210: server log: timeout waiting for SETTINGS frames from 127.0.0.1:61917
            sniff_test.go:236: Get: Get "https://127.0.0.1:61916": unexpected EOF

— watchflakes

[gopherbot]

Found new dashboard test flakes for:

#!watchflakes
post <- pkg == "net/http" && test == "TestContentTypeWithVariousSources"

2022-12-01 21:00 freebsd-arm-paulzhol go@93587d35 net/http.TestContentTypeWithVariousSources (log)

--- FAIL: TestContentTypeWithVariousSources (0.00s)
    --- FAIL: TestContentTypeWithVariousSources/h2 (5.52s)
        --- FAIL: TestContentTypeWithVariousSources/h2/write_one_byte_at_a_time (3.25s)
            clientserver_test.go:210: server log: timeout waiting for SETTINGS frames from 127.0.0.1:61917
            sniff_test.go:236: Get: Get "https://127.0.0.1:61916": unexpected EOF

— watchflakes

[bcmills]

The timeout in question appears to be http2firstSettingsTimeout:
https://cs.opensource.google/go/go/+/master:src/net/http/h2_bundle.go;l=3795;drc=119f679a3bd2e60cfc990920f82fd1a5cb006f4c
https://cs.opensource.google/go/go/+/master:src/net/http/h2_bundle.go;l=4711;drc=119f679a3bd2e60cfc990920f82fd1a5cb006f4c

It isn't clear to me whether that timeout is arbitrary or actually defined or recommended in the HTTP/2 RFCs (maybe @neild knows?).

I also seem to recall some discussion with @paulzhol about upgrading the builder to avoid scheduling stalls, but I can't find it now. 😅

[paulzhol]

I've upgraded the builder a while back (six months?) the dashboard just got updated for it recently http://golang.org/cl/420354.
And the unexpected EOF makes me think this could be the RST theory of #57476 (comment).