Attribute aliasing

Title: Attribute aliasing Description: Often times, control planes and higher layers expose user friendly attributes that do not map directly to an Envoy attribute. e.g., source.foo that may be obtained from filter_state['com.blah']['scooby']. In other cases, there are naming skews. e.g., envoy's attribute connection.requested_server_name is referred to in Istio or other places as connection.sni. source.address in Envoy is source.ip in some other places.

Where does this become a problem? Imagine that the higher level API is exposing a CEL expression that can be crafted by the end user. Say the end user's expression is source.ip != 1.1.1.1. This wont evaluate within Envoy because there is no source.ip attribute. The control plane is now forced to either do a clunky search and replace of strings like source.ip, source["ip"], etc. to source.address. This is not only clunky but also very error prone.

Another area where this is a problem is in ext_proc. we have forward_attributes field in the ext_proc. Users may say forward source.foo (a user friendly attribute exposed by the higher level APIs). They may write their ext_proc servers to expect this exact attribute in the ProcessingRequest. However, if the control plane were to replace source.foo with filter_state[com.blah][scooby], the attribute in the ProcessingRequest will be filter_state[com.blah][scooby] and not source.foo. The ext_proc server will fail if it depends on this attribute for its processing.

To help both of these scenarios, we need some form of custom attribute provider in Envoy wherein one could define the attribute name and the source for these attributes. for example a filter configuration could be like:

connection.sni: connection.requested_server_name
source.foo: filter_state[com.blah][scooby]

Then in the RBAC filter's CEL expression or in ext_proc, whenever the user specifies an attribute like source.foo that is not native to Envoy, this attribute provider class if present is invoked to return the appropriate value.