v2 tcp proxy filter config with deprecated_v1 field conflict

[junr03]

Description:
Currently, when the listener is creating network level filters, it uses the deprecated_v1 field as a boolean indicator to load a v1 config from an opaque value field.

envoy/source/server/listener_manager_impl.cc

Lines 41 to 46 in d6b8b07

	if (filter_config->getBoolean("deprecated_v1", false)) {
	callback = factory.createFilterFactory(*filter_config->getObject("value", true), context);
	} else {
	auto message = Config::Utility::translateToFactoryConfig(proto_config, factory);
	callback = factory.createFilterFactoryFromProto(*message, context);
	}

. However, this approach conflicts with the actual deprecated_v1 field in the tcp proxy config https://github.com/envoyproxy/data-plane-api/blob/master/api/filter/network/tcp_proxy.proto#L113. This means that it is not possible to use a v2 tcp filter config with a deprecated_v1 field in it.

So for example, this config will fail:

- address:
    socket_address: {address: 0.0.0.0, port_value: 9414, protocol: TCP}
  filter_chains:
  - filters:
    - name: envoy.tcp_proxy 
       config:
        deprecated_v1: {cluster: foo}
        stat_prefix: foo

[junr03]

cc @danielhochman @mattklein123 related to what happened at lyft tonight.
cc @htuch

[mattklein123]

@junr03 I don't really see us fixing this. To workaround this I think you can just use v1 JSON config for tcp_proxy inside the v2 deprecated_v1 holder, right? I think we should just do a doc warning to "fix" this issue.

[junr03]

ok, I will add the warning.

[mattklein123]

Fixed

[CamiloGarciaLaRotta]

Just a heads up:

The latest commit to envoy/config/filter/README, which is pointed to in the Attention box in the TCP proxy documentation, removes the example on how to use the deprecated_v1 field.