[Feature Request] Machine Parsable Validation Output

Currently running the envoy server in "validate" mode presents the user with output that is meant to be human readable, but can be monstrous to someone new to envoy:

     Proto constraint validation failed (HttpConnectionManagerValidationError.RouteConfig: ["embedded message failed validation"] | caused by RouteConfigurationValidationError.VirtualHosts[i]: ["embedded message failed validation"] | caused by VirtualHostValidationError.Domains: ["value must contain at least " '\x01' " item(s)"]): stat_prefix: "ingress_http"
[...]

(I've snipped some of the output here, but if you want to test this yourself the example config file is HERE ).

This output is great if you're very familliar with envoy, but as a user who is just "using" envoy, without deep knowledge of it's internals this output is essentially unreadable. The user has to somehow translate the actual error is that their config item:

static_resources.listeners[0].filter_chains[0].filters[0].route_config.virtual_hosts[0].domains

is empty. And yes the error message is there:

caused by VirtualHostValidationError.Domains: ["value must contain at least " '\x01' " item(s)"]

but it's buried with all this output that is helpful only sometimes, or only to some.

Now obviously this is a rather contrived error message chosen specifically because it "looks bad", there are some that do correlate their meaning for most users like invalid_host:

malformed IP address: localhost. Consider setting resolver_name or setting cluster type to 'STRICT_DNS' or 'LOGICAL_DNS'

But the more general idea is that some error messages as they're being created, or developed may not be useful to everyone.

We'd like to float the idea by (and potentially implement) that envoy should generate "machine readable error messages" (e.g. json) when asked too (perhaps controlled through a CLI Param)? This way users can build tooling around the error messages of envoy, and build custom error messages where they feel is necessary. So you might get a malformed host exception like (this is just an example off the top of my head, in no way saying this should be even close to the final output):

{"exception_type": "malformed IP address", "exception_data": {"ip": "localhost"}}

Which a tool could then turn into whatever it considers to be "helpful". This would obviously need to be expanded to other exception types as well but the general idea is that each exception type gets a unique identifier in something machine parsable that a tool can then turn into a user facing error message if it feels it needs too. Meanwhile users who either don't care, or like the existing error messages do not have to generate error messages in json.