feat: add grpc reflection support

[jacobowitz]

This PR allows external Executor to be fronted by our gRPC Gateway. This enables us to deploy external Executors together with a Gateway (as Executor.serve() is doing.). In theory this also allows us to integrate complete Flows as external Executors into another Flow. See the tests for some examples.

Implementation details:
I've added support for gRPC reflection with this PR. When we add a new connection, we first check the available gRPC endpoints using reflection. This way we can figure out automatically if the GrpcConnctionPool is used to target a Worker/Head or Gateway. This is necessary because they have different gRPC interfaces (streaming and non streaming). There is no configuration necessary to enable this. The reflection call is done lazily before the first request is send to the target.

• Support reflection via grpc. Find out if the target is gateway or head/worker. Create the right stubs and hide this in the GrpcConnectionPool
• Add test case for the g2g scenario
• Check on parsing that merging is not required at the external Executor
• Mention merge limitations in docs

Closes #4556

Unblocks: #4502

[github-actions]

Latency summary

Current PR yields:

• 🐎🐎🐎🐎 index QPS at 1156, delta to last 2 avg.: +11%
• 🐎🐎🐎🐎 query QPS at 64, delta to last 2 avg.: +23%
• 🐢🐢 avg flow time within 1.0674 seconds, delta to last 2 avg.: -33%
• 😶 import jina within 0.468 seconds, delta to last 2 avg.: -2%

Breakdown

Version	Index QPS	Query QPS	Avg Flow Time (s)	Import Time (s)
current	1156	64	1.0674	0.468
3.2.10	996	50	1.6439	0.5042
3.2.9	1078	53	1.5694	0.4579

Backed by latency-tracking. Further commits will update this comment.

[codecov]

Codecov Report

Merging #4585 (09902bf) into master (bdad931) will increase coverage by 0.00%.
The diff coverage is 90.12%.

@@           Coverage Diff           @@
##           master    #4585   +/-   ##
=======================================
  Coverage   87.70%   87.71%           
=======================================
  Files         117      117           
  Lines        8411     8464   +53     
=======================================
+ Hits         7377     7424   +47     
- Misses       1034     1040    +6     

Flag	Coverage Δ
jina	87.71% <90.12%> (+0.02%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
jina/serve/networking.py	86.59% <87.69%> (+0.83%)	⬆️
jina/orchestrate/flow/base.py	89.90% <100.00%> (+0.03%)	⬆️
...ina/serve/runtimes/gateway/graph/topology_graph.py	100.00% <100.00%> (ø)
jina/serve/runtimes/gateway/grpc/__init__.py	94.73% <100.00%> (+0.29%)	⬆️
jina/serve/runtimes/head/__init__.py	92.59% <100.00%> (+0.16%)	⬆️
jina/serve/runtimes/worker/__init__.py	94.11% <100.00%> (+0.27%)	⬆️
...a/orchestrate/deployments/config/docker_compose.py	98.97% <0.00%> (-1.03%)	⬇️
.../runtimes/request_handlers/data_request_handler.py	92.10% <0.00%> (-0.88%)	⬇️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update bdad931...09902bf. Read the comment docs.

[JoanFM]

can't we avoid this and simply initialize at __init__ time? I prefer a more stateless approach

[jacobowitz]

unfortunately not. The lazy init here is connecting to the server's grpc reflection endpoint, but the init is called on adding connections. At this time the server might not be ready yet. This is why I am delaying this until sending of the first data request. Then the server should be ready (or the request would fail anyway).

[github-actions]

📝 Docs are deployed on https://feat-g2g-external--jina-docs.netlify.app 🎉