Setup services from configuration

[adam-cattermole]

Changes

Builds on top of the GrpcServiceHandler added previously to configure these at the plugin configuration stage:

Most of the fields in the GrpcServiceHandler had a lifetime that was for the duration of the wasm filter (the stuff read from configuration), but the lifetime of the header resolver is only for each http request. I've moved these fields out to a new GrpcService.

GrpcService

• The method and name currently come from a static variable, so I'm using &'static str for these instead of String as I didn't want to create copies of these just to convert them back to references in send
• The GrpcService currently also contains the failure_mode now instead of storing this config-wide

Update Configuration

• A new extensions field has been added to the PluginConfiguration that is defined as follows:

"extensions": {
    "limitador": {
        "type": "ratelimit",
        "endpoint": "limitador-cluster",
        "failureMode": "deny"
    }
},

• I have updated the configuration to build the set of GrpcServices from the extensions deserialised in the initial step of the TryFrom - for now I'm storing them as an Rc<HashMap<String,Rc<GrpcService>>> - the String being the key of the extension that can be used to reference which service from the actions.
  • Perhaps we can iterate on this storage structure - I chose to use an Rc for the HashMap so that it can be re-used across all http requests as these are configured from the plugin config. However I also chose to have the GrpcServices as an Rc so that the ref can be cloned to each of the GrpcServiceHandler
• Currently this is used by taking the first GrpcService and using that as the service. Once we have an idea of how the actions will be defined we could retrieve the correct service for the action

[adam-cattermole]

I've removed this rename, so it's no longer rateLimitPolicies and now just policies

[didierofrivia]

🍬