Enrich policy input

[mostafa]

Ticket(s)

Closes #462.

Description

This PR adds hook information to the policy Input data. This adds yet another piece of information that can be leveraged by policies with better granularity. These are now passed to the policies:

1. Hook.Name: the name of the plugin hook that was run and received the Act signals.
2. Hook.Priority: the priority of the plugin hook. This shows at which point from the top of the list of registered hook the plugin hook was called from.
3. Hook.Params: the parameters passed to the plugin hook.
4. Hook.Result: the result of running the plugin hook. This is usually a superset of the Hook.Params, because the plugin hook must return the same request that was passed to it by the Hook.Params.

This feature will work with all the future signals, policies and actions and will enable a lot of interesting use cases. For example, these initial scenarios and policies can be written after merging this PR:

1. The current terminate policy can be updated to check for IP address of the incoming client or outgoing connection to the database. The example below means that terminating the request only happens if the request isn't coming from 127.0.0.1 (localhost). Note that the trafficData internal help function injects these values into the parameters that are passed to the plugin hook.

   policies:
     - name: terminate
       policy: |
         Signal.terminate == true &&
         Policy.terminate == 'stop' &&
         split(Hook.Params.client.remote, ':')[0] != '127.0.0.1'
       metadata:
         terminate: "stop"

2. We might want to terminate a request, but only log an audit trail (as an error) if the request doesn't come from an specific IP address:

   policies:
     - name: log
       policy: |
         Signal.log == true &&
         Policy.log == 'log' &&
         split(Hook.Params.client.remote, ':')[0] != '192.168.0.1'
       metadata:
         log: "log"

TODO

• Enrich policy input docs#55
• Create helper functions to make writing policies easier #541

Related PRs

• Add Hook to the policy Input for enrichment gatewayd-plugin-sdk#33

Development Checklist

• I have added a descriptive title to this PR.
• I have squashed related commits together.
• I have rebased my branch on top of the latest main branch.
• I have performed a self-review of my own code.
• I have commented on my code, particularly in hard-to-understand areas.
• I have added docstring(s) to my code.
• I have made corresponding changes to the documentation (docs).
• I have updated docs using make gen-docs command.
• I have added tests for my changes.
• I have signed all the commits.

Legal Checklist

• I have read the CONTRIBUTING document.
• I have read and understood the Code of Conduct.
• I have read and agreed to the Apache CLA (required).
• I have read and agreed to the LICENSE (required).

[Hamsajj]

Looks good to me! great feature and use-cases.

I only have on minor comment. Maybe it is good to have a test with an actual policy that uses some hook result (like the log example in the PR description)
That can work as a test, but also as a great example on how this new feature can be helpful and accessed in policies,

[mostafa]

@Hamsajj

Tried to address your comments in 78203ed.

[Hamsajj]

Great! I have no more comments 🚀