Refactor entire filter flow

[adam-cattermole]

Changes

In this PR I've refactored the existing approach which had become somewhat unwieldy. I have tried to clean up the commits here, but it's worth noting this was an iterative process, and so some of the changes in the initial commits are changed/reverted in subsequent ones.

The main principle is as follows - I have aimed to reduce the leaking of the wasm/envoy hostcalls across every layer and instead delegate this to the filter. The filter has knowledge of the different 'phases' (on_http_request.. on_grpc_call_response..), and simply just performs Operations based on it's current state and what it is being asked to do. The configuration itself remains unchanged, and the concerns of building and consuming of the specialised message types is delegated to the owner (auth_action/rl_action). The filter has no knowledge of the individual actions but instead uses the RuntimeActionSet to initiate the flow, and from then on the Operations to determine what to do next.

Each of the operations tell the filter it must do something (that the layers below should not and do not know about):

• SendGrpcRequest: This informs the filter it needs to make a GRPC call and contains all of the the information it requires to make the request - the filter does not need to know which action/service this relates to
• AwaitGrpcResponse: This tells the filter that there is nothing left to do within the current method and it must pause to await a GRPC response
• AddHeaders: This tells the filter it must add headers to the response in the required phase
• Die: This informs the filter that it is finished due to an error and must send a response before it finishes - this may not be an "error" due to a failure, but is also used for the case where we must return an error code to the caller (i.e. 401 Forbidden, 429 Too Many Requests..)
• Done: This informs the filter that it has successfully finished operating and the request may be resumed

The specialised actions currently handle both the building of messages to the transfer type, and conversion to the message they expect. I have also made some decisions on how these actions return information to the layers above, based on the different operations the filter may have to perform.

Outstanding

There are several outstanding things to address (in follow up work):

• Currently some parts of the logic are based around whether there is a message to send or not, this could be reworked to determine whether we have anything to do, for example our action just requires us to add headers and not send a message
• Whilst the hostcalls have been removed in lots of places throughout the code, there are still uses through the set/get_property calls, this would ideally be replaced with some kind of resolver layer with memoization
• To keep an abstraction between the KuadrantFilter, Operations, and RuntimeActions there was a need to retain the index of the current active RuntimeAction within some Operations (to progress the flow). I would like to investigate eliminating this, potentially by building the chain of Operations up front (where each contains self + next). Another alternative might be implementing the iterator trait so we can just call .next() to go through each

[alexsnaps]

I feel I'm not the right person to review this, as I've been kept in the loop all along. So needless to say its a 👍 from me.
Is it perfect? Probably not... Are there bugs? Possibly yes... But it doesn't matter, it's all in my opinion a whole cleaner than it was! And we can keep on iterating as we add new features & capabilities to this component.

What might be useful is for people to use to PR to record and track (in issues?) what the agreed upon next steps would be? If this is an acceptable starting points for others too obviously.