feat: Add external plugins support - DO NOT MERGE

[mayabar]

Add initial version of server side support for external HTTP plugins.
Add sample filter plugin implemented in python

Fixes: #163
Fixes: #164
Fixes: #184

[elevran]

I did not review beyond the first or second file.
IMO, this PR might be too big to review in one go and could benefit from breaking up (e.g.,):

• design doc/proposal (which should be approved separately)
• API definitions (e.g., JSON between client and server)
• sample server (e.g., python) and client, for a fixed function.
• improved client (e.g., configuration of http.Client for timeout handling, etc.)

There is no need to support all plugin types at once. Furthermore, since configuration via file is forthcoming, I would delay writing configuration code until it is merged. Otherwise it's throwaway code.

[elevran]

q: what's the benefit of using a non standard HTTP implementation? If performance, then we should first prove that HTTP handling is a bottleneck.

[elevran]

At this point the external process plugin is for demo only, so I would refrain from introducing and using all these environment variables (which would be eliminated by the config changes anyway).

[elevran]

For a demo, you can just enable (or not) a fixed type plugins (e.g., filter or scorer) at a well known address (e.g., localhost:8000/8088 and run their container(s) in the same Pod)

[elevran]

import order seems wrong

[nirrozenbaum]

@elevran what’s the intention about this PR?
is it planned to be completed?
This PR seems to be open almost 2 months

[elevran]

It is not intended to be merged at this time and was created to share ideas with community and to solicit feedback (the concept of out of process plugins was presented at a community meeting and had corresponding code for those interested).
Having an open PR is probably not the best way for this discussion, but we may want to have something tangible (not necessarily this PR) for people to experiment with.
Open to suggestions.

[nirrozenbaum]

one option would be to create a branch called experimental-out-of-process-plugins (or something alone these lines) and keep this code there.
it allows experimenting with it, and also to create a PR to main at any given point if we think it becomes relevant.
not sure that holding an open PR for this purpose is the right approach.

[elevran]

Agree.
Let's clean it up as you suggested to a branch at earliest convenience (pre/post release - I don't think there's urgency)