This reverts #3063, which reverted #3030, which reverted #3018, which reverted #2999. Therefore this PR is similar to #2999, except that

• REST/gRPC config mismatch errors now warn instead of throwing an error. Hopefully this solves the issue for users who were unable to roll forward their binaries while keeping the same config.
• a related issue where API configs of type GRPC were implicitly assumed to have a grpc_services field set is now fixed. (see 32dae12.) Support for GRPC configs with cluster_names set instead of grpc_services will extend through release 1.7.0.

Changelist for #2999:

To support the deprecation of cluster_names in the api_config_source (#2860), I

• added a more verbose error in utility.cc for GRPC api_config_sources with any named clusters
• hunted down places in tests where api_config_source.cluster_names()[0] was implicitly used (assuming that API would be GRPC and would have cluster names).
• renamed factoryForApiConfigSource to factoryForGrpcApiConfigSource, as it already implicitly returns a Grpc::AsyncClientFactoryPtr, and gave a more verbose error for when the user passes a config with cluster_names set.
• separated out checkApiConfigSourceSubscriptionBackingCluster into checkApiConfigSourceNames, which does the gRPC services v. cluster names validation, and checkApiConfigSourceSubscriptionBackingCluster, which actually validates the cluster name against the clusters map.
• more completely covered the tests for the branching cases for non-gRPC API configs which happened to have grpc services defined.

Risk Level: Low

Testing: bazel test test/... all passed.

Fixed #2680
Fixed #2902

Signed-off-by: James Buckland jbuckland@google.com