✅ Initial integration tests

[evaline-ju]

Summary

Initial integration tests that leverage an actual grpc server (note the added tests do not depend on/use an MCP gateway)

Related issue(s)

Fixes #42

[julianstephen]

Thanks, @evaline-ju. This is pretty neat. Integration tests could be pretty useful. Couple of questions for my understanding:

1. When we are mocking the envoy modules, is this getting routed straight to server.py or the plugin itself from the integration tests?
2. What are we testing in passthrough_plugin/plugin.py ? Do we want to use these as a template for more detailed integration testing (which would be nice)? Trying to understand why we are testing a 'new' plugin, which we are not using.

[evaline-ju]

@julianstephen thanks for taking a look!

1. When we are mocking the envoy modules, is this getting routed straight to server.py or the plugin itself from the integration tests?

The envoy module mocking was present in the unit tests and aren't used for the integration tests added here in this PR. I assume this is in reference to the comment update for "Server unit tests" in the CI workflow update. The integration tests here spin up a real gRPC server with the actual ExtProcServicer from server.py.

The flow in integration tests is: test → real gRPC stub → ExtProcServicer (server.py) → PluginManager → PassthroughPlugin

2. What are we testing in passthrough_plugin/plugin.py ? Do we want to use these as a template for more detailed integration testing (which would be nice)? Trying to understand why we are testing a 'new' plugin, which we are not using.

The passthrough plugin is deliberately a test-only fixture plugin to allow the simple allow/block cases (since this adapter isn't doing much more right now). Mainly it avoids additional external services and having to mock those (like for the nemocheck plugin example). It could serve as a template for more detailed integration tests with other plugins — the pattern of the test plugin and real gRPC server is basically reusable.