Per-extension empty message configs

[htuch]

In v2, we used google.protobuf.Empty for the configuration for simple extensions that didn't require custom configuration. Now that we have Any as the canonical method for specifying extensions, this doesn't work as well, since it makes it difficult to move to a versioned per-extension message without breaking wire compatibility within a major version.

As part of the v3 works, we should give each existing filter that relies on google.protobuf.Empty a custom empty config message in v3 and deprecate the use of WKT here.

[derekargueta]

@htuch Mind checking that I'm moving in the right direction? https://github.com/envoyproxy/envoy/compare/master...derekargueta:dereka/empty-proto?expand=1 Pretty straightforward - for every extension that is using Envoy::ProtobufWkt::Empty, create a proto with an empty message and replace it - but want to verify before I go on to HTTP filters

As for defensively preventing new extensions from using Envoy::ProtobufWkt::Empty, I'm thinking a check_format.py check?

[htuch]

@derekargueta looks good! The main thing we need to do in addition to what you have is allow Empty to continue working until we delete v2. When filter config comes in via an Any, the type URL needs to match whatever the filter expects. The way I would tackle this is in places like

envoy/source/common/config/utility.cc

Line 270 in 81d3beb

if (!typed_config.value().empty()) {

, we have a special case for Empty.

[derekargueta]

ah right, can't swap atomically or it'd break wire compatibility with v2 xDS servers. Will do some spelunking around envoy/source/common/config/utility.cc, can't say I'm super familiar with this area of the codebase yet, but from what you're saying I'm inferring that I'm clear to continue this approach and that the Empty protobuf can be indirectly handled through these utility routines. In the meantime I'll go ahead and finish out the HTTP filters too.

[htuch]

@derekargueta any update on how this is tracking for EOY?

[kyessenov]

xref: #9358
This issue basically ensures uniqueness of config proto by filter in a category.
@derekargueta I can land a helping hand to push this through if you want.

[derekargueta]

I'll have this done by Thursday EOD (shooting for tomorrow though). Thanks for offering help @kyessenov, I'll ping you on Slack if I need anything.

[derekargueta]

Have all the new proto files ready here, the strategy I'm going down to support ProtobufWkt::Empty (somewhat based on the diff @kyessenov started - https://github.com/envoyproxy/envoy/pull/9391/files#diff-17967d56376bf9821edb17b67b8a7e63R180) is adding a usesGoogleProtobufWktEmpty() (or similar) to FactoryRegistry defaulting to false, then in the applicable factories override it to true. This way extensions can be looked up in the registry using the proto type name, but before returning the empty proto we can check if the factory is supposed to use ProtobufWkt::Empty for the wire. An alternative is using a protofbuf option, which I'm less familiar with. The last catch is that when we cut v3, we want to stop using ProtobufWkt::Empty and switch to the empty per-extension message.

Also, since we're coming to a tight deadline I'm fine letting someone else carry this across. I'm a bit resource-constrained at the moment with impending change freeze.

[htuch]

@derekargueta awesome, I like this plan. Thanks a bunch for doing all the ground work here. I think we shouldn't have to do a ton in terms of converting between typed protos, it's mostly about replacing type URLs during Any/TypedStruct conversion; on the wire, ProtobufWkt::Empty and the per-filter empty protos are identical modulo type URL.

@kyessenov if you have cycles to lend a hand taking us towards the ability to express filter type in the v3 APIs via config type, this is the PR :D

[htuch]

@derekargueta @kyessenov do either of you have cycles to land this in the next week (prior to 1.13.0)? Would be great to do this and align with #9391.

[kyessenov]

@derekargueta I can take over the branch if you're OK. We just need to provide empty protos for all filters.

[derekargueta]

@kyessenov yes feel free, I'm currently trying to fix clang-tidy, and have another internal request to implement 😓

[htuch]

Fixed in #9581