ext_proc: Add per-route configuration

[gbrail]

Commit Message: ext_proc: Add per-route configuration for processing mode and "disabled" flag.
Additional Description:
Risk Level: Low. Not triggered unless configured.
Testing: New unit and integration tests added.
Docs Changes:
Release Notes:
Platform Specific Features:

[repokitteh-read-only]

As a reminder, PRs marked as draft will not be automatically assigned reviewers,
or be handled by maintainer-oncall triage.

Please mark your PR as ready when you want it to be reviewed!

🐱

Caused by: #17691 was opened by gbrail.

see: more, trace.

[repokitteh-read-only]

CC @envoyproxy/api-shepherds: Your approval is needed for changes made to api/envoy/.
envoyproxy/api-shepherds assignee is @markdroth
CC @envoyproxy/api-watchers: FYI only for changes made to api/envoy/.

🐱

Caused by: #17691 was opened by gbrail.

see: more, trace.

[wrowe]

Ping @markdroth?

[soulxu]

thanks for update, lgtm

[markdroth]

/lgtm api

[snowp]

Thanks, looks good just one question

/wait

[snowp]

Is this how the other per route configurations work? I may be misremembering but I thought most they wouldn't merge, but pick the most specific one

[gbrail]

I find this confusing myself. I copied the language in the .proto from the ext_authz proto, which says, "If disabled is specified in multiple per-filter-configs, the most specific one will be used."

I think that this is the right logic for this. In the future, we'll implement overrides for request and response properties, and in that case I think that we might want to try and merge them if that makes sense.

[gbrail]

So for the two properties that are supported today, the behavior is indeed to pick the most specific one -- but we might choose something different for the properties that aren't supported yet.

[soulxu]

If the most specific one is your choice, then sounds like using this method is most simple for you (Sorry, I missed that from previous review)

envoy/source/common/http/utility.h

Lines 495 to 501 in 17b24c7

	/**
	* The non template implementation of resolveMostSpecificPerFilterConfig. see
	* resolveMostSpecificPerFilterConfig for docs.
	*/
	const Router::RouteSpecificFilterConfig*
	resolveMostSpecificPerFilterConfigGeneric(const std::string& filter_name,
	const Router::RouteConstSharedPtr& route);

Also, the properties ExtProcOverrides overrides is named as overrides, so it doesn't sounds like extendable for future you want to merge them also.

ExtAuthz using the merge logic, but it is mixed also.

https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/filters/http/ext_authz/v3/ext_authz.proto#envoy-v3-api-msg-extensions-filters-http-ext-authz-v3-checksettings

Only the context_extensions has the merge logic, Other fields is the most specific one logic.

Maybe we can follow the ExtAuthz, don't name the field with override name, or we design something else to explicitly specific override or merge.

[snowp]

After chatting a bit with other maintainers I think this is fine, as the behavior appears to be documented.

[snowp]

Sorry for the delay here, this seems good to me.