"verify_subject_alt_name" should accept an array of strings

[lookuptable]

This commit cleans up a few leftovers from #559 .

[lookuptable]

CC @myidpt @wattli

[wattli]

LGTM, but I can't approve it.

[lookuptable]

@mattklein123 PTAL

BTW is there any existing test cases for config_schemas.cc? If yes can you please point me to the test file?

[mattklein123]

@ccaraman can you take a look at this? I'm a little confused how this passed tests even without the schema change?

[mattklein123]

@lookuptable please sign CLA also

[lookuptable]

@mattklein123 Signed!

[ccaraman]

@mattklein123 It passed because the ssl_context are checked in two places Json::Schema::LISTENER_SCHEMA and Json::Schema::CLUSTER_SCHEMA.

A more complete fix would be to pull the SSLContext into its own schema and move the check into https://github.com/lyft/envoy/blob/9dcac8ca111ecc8da059d1f8d42eb766b44bacd6/source/common/ssl/context_config_impl.cc#L17 I can do this later this week.

@lookuptable No, we don't have tests for explicit tests for our schemas other than some places where we load a config that we expect to fail. I've added #572

[mattklein123]

Yes, but for the change to configgen.py, how did that pass tests previously. That is related to upstream. That should generate a config that does not load. Do we not test that case in the example config tests?

[mattklein123]

@lookuptable it's not perfect, but you should be able to add a test for a listener that sets verify_subject_alt_name like here: https://github.com/lyft/envoy/blob/master/test/server/configuration_impl_test.cc#L124

I'm guessing in the configgen.py case, we just don't generate an example config with dynamo in it, since I know I fixed this case in our internal configs.