net/http/internal/http2: don't shrink HPACK decoder table before SETTINGS ack

A server configured with a MaxDecoderHeaderTableSize below the initial
4096 bytes (RFC 7540, section 6.5.2) applied it to its HPACK decoder at
connection start. But the server doesn't know when the client has
received and applied a SETTINGS value until the client acknowledges the
SETTINGS frame (RFC 7540, section 6.5.3), and the client's encoder
signals a table size reduction with a dynamic table size update at the
beginning of the first header block following the settings
acknowledgment (RFC 7541, section 4.2). Until then, the client may keep
using the initial 4096-byte table. A spec-compliant client (including
Go's own http2 client) that sent a header block referencing a dynamic
table entry in the first RTT was rejected with a connection-fatal
COMPRESSION_ERROR.

Instead, start the decoder at the initial table size and apply the
configured smaller size once the client acks our SETTINGS. All header
blocks after the ack were encoded by a client that has processed the
setting, and a compliant encoder begins its next header block with a
dynamic table size update. Memory during the window is bounded by the
same 4096 bytes as today's default.

Change-Id: Idecd25a1e0473c3cff314922ddc97ace14cb2e5e
Reviewed-on: https://go-review.googlesource.com/c/go/+/827024
Reviewed-by: Nicholas Husin <husin@google.com>
LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Nicholas Husin <nsh@golang.org>
Auto-Submit: Brad Fitzpatrick <bradfitz@golang.org>