HTTP/2 improvements for CVE-2023-36478

[sbordet]

Addressing CVE-2023-36478

• Implemented a few required error handlings.
• Changed Parser.init() to directly take the listener, rather than wrapping it. The reason for this change was to be able to reconfigure the Parser upon receiving a SETTINGS frame.

[gregw]

This is only a partial review, as I have lots of questions and am -0 on somethings.
Perhaps we need to hangout, but it would be good if the comments/javadoc was good enough so that explanation of these things was not needed.

My comments were addressed

[sbordet]

@lachlan-roberts I think there is an inherent race that cannot be fixed unless delaying the use of API until both initial SETTINGS frame have been acknowledged.

For example, the client has no special configuration, all defaults, so client.decoder.maxTableCapacity=4096.
The client sends the initial SETTINGS frame that may or may not contain that value.
Then the client can send a request that may or may not contain the instruction to resize the table.

Meanwhile the server has not sent the initial SETTINGS frame, but it is configured so that its decoder has server.decoder.maxTableCapacity=0.
The server does not read until it has sent the initial SETTINGS frame; when it reads, it reads the client's SETTINGS, which applies to its encoder, and then it reads the request that has been sent using the default values, which may contain a resize instruction that is invalid for the server decoder configuration.

The specification says, section 3.4 of RFC 9113:

To avoid unnecessary latency, clients are permitted to send additional frames to the server immediately after sending the client connection preface, without waiting to receive the server connection preface.

So it is clear that the spec allows for this window to happen.
Waiting for the SETTINGS reply does not help, as the client should wait for the server initial SETTINGS, which is not mandatory as the above paragraph says.

So yes it's racy, but it is allowed, and it has been fixed in HTTP/3 where the table initial sizes are 0 and all communication about table sizes happens as parts of HEADERS frames.

However, I filed #9801 about this.

[lachlan-roberts]

Looks good. All my comments have been addressed.

We have some pre-existing race conditions which will be address separately as part of #9801 so I am happy to go ahead and merge this one.