[ext_proc] Add extension point to run custom logic after onReceiveMessage

[pradeepcrao]

Commit Message:
Additional Description:

Fixes #34501
Risk Level:
Testing:
Docs Changes:
Release Notes:
Platform Specific Features:

[repokitteh-read-only]

CC @envoyproxy/api-shepherds: Your approval is needed for changes made to (api/envoy/|docs/root/api-docs/).
envoyproxy/api-shepherds assignee is @adisuissa
CC @envoyproxy/api-watchers: FYI only for changes made to (api/envoy/|docs/root/api-docs/).

🐱

Caused by: #37916 was opened by pradeepcrao.

see: more, trace.

[adisuissa]

Thanks!
Left a few high-level questions to start a discussion.
Also assigning @yanjunxiang-google and @tyxia as code-owners.
/assign @yanjunxiang-google @tyxia

[adisuissa]

Please add a comment describing this extension. This should also clarify what types of extensions are allowed here.
It is unclear when this decorator is executed in the on-receive path (before processing the message or after). I'm assuming the former but this should be clarified.

[adisuissa]

A few high-level questions/discussions:

1. should this be a repeated field? would there be a need to invoke multiple decorators, or is the expectation that in this case a single decorator that invokes multiple decorators will be used (composed decorators)?
2. Will it make sense to have a different decorator for the different steps (onHeaders/onData/onTrailers). I'm assuming not, or rather there should be different callback methods in a single decorator, but I want to make sure this was considered.
3. Is this "reinventing" the filter lifecycle? I'm guessing we are not there yet (in terms of requirements), but if this is heading in that direction, then maybe we can adopt a few things from the filter interface.

[pradeepcrao]

Thank you for the review Adi!

The decorator runs after the ext_proc filter has processed the message from the external processor. That way, we can react to the processing_status and handle errors appropriately.

1. It makes more sense for me to use a single decorator that might invoke multiple actions. This is meant to be lightweight, and not fundamentally alter the ext_proc filter behaviour.

2. Having a single decorator for all message types makes more sense. The logic for handling different message types can be implemented in the decorator itself.

3. The decorator onReceiveMessage method takes the side stream response from the external processor, and the processing_status of the ext_proc filter as inputs, which is very specific to the ext_proc filter. I am not aware of how we can adopt anything from the filter interface for this use case.

[pradeepcrao]

Also, is there a canonical way I can document that the extension config specified here is meant to work with the OnReceiveMessageDecorator interface?

[yanjunxiang-google]

Based on #34501, it seems there are different options for supporting this.
@tyxia could you please take a look?