[api] Fix header validations

[asraa]

This enables "non-strict" header validations, that match the ones in place with Envoy's ASSERT(valid()) code. The default strict: true checks checked for RFC-compliance, which may break previously valid configs.

Part of #10318

Signed-off-by: Asra Ali asraa@google.com

[repokitteh-read-only]

CC @envoyproxy/api-shepherds: Your approval is needed for changes made to api/.

🐱

Caused by: #10335 was opened by asraa.

see: more, trace.

[asraa]

@antoniovicente @htuch @hennna @yanavlasov

[asraa]

I wanted to get this patch ready ASAP as a fix, but TODO to find the appropriate way to flip the strict validations. Thoughts? Deprecation and new wrapped message? Add hook (with flag to flip) to make strict in a newer version/log message about it MessageUtility::Validate?

[htuch]

LGTM. I don't think we can feature flip strict validation, as that is basically feature flipping API features. This violates the "PGV is stable like the proto" property.

[alyssawilk]

@htuch, are we comfortable with this from a stable API perspective?

[asraa]

@htuch, are we comfortable with this from a stable API perspective?

The goal was to align them to stable API policy :) the checks here mimic those done in debug asserts, which provides the implied contract we don't expect to have \r\n\0 in header names/values

[htuch]

@alyssawilk yeah, this basically undoes the API breaking change in #10093 by replacing it with something that was strongly implied in the API.