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.