Rationalise HTTP_WRONG_SETTING_DIRECTION error

[LPardue]

HTTP_WRONG_SETTING_DIRECTION presently applies to exactly one case, a client that sends NUM_PLACEHOLDERS. Declassifying this as an error seems like a sensible option. This frees up error code 0x1, which we can move HTTP_GENERAL_PROTOCOL_ERROR to (making HTTP/3 more similar to HTTP/2).

My initial preference is to state that servers MUST ignore this value if present. I'll prepare a PR to that effect.

[LPardue]

I forgot to mention that @MikeBishop made an observation that SETTINGS errors are presently also covered by MALFORMED_FRAME, which is also on the chopping block.

An alternative solution is therefore to create an INVALID_SETTINGS that covers all the ways that a SETTINGS frames could go wrong.

[kazuho]

Thank you for opening the issues.

While I agree that we do not need an error code specific to SETTINGS going in the wrong direction, I am not sure if declassifying it as an error is the right option. Not that I have a strong opinion, but IIRC our consensus is to be more strict against misbehaving peers in HTTP/3 compared to HTTP/2.

MALFORMED_FRAME or INVALID_SETTINGS sounds like a more conservative fix to me.

[LPardue]

Thanks @kazuho, after suggesting this I changed my mind. I made #2814 to implement the change as you and Mike suggest. The nice side effect is that it takes one step away from MALFORMED_FRAME.