feat(routing): add static routing table feature

[jacobowitz]

This adds the new parameter static_routing_table to the Flow. By default this parameter is disabled.

If this parameter is enabled, the Flow will precompute the routing table for all Pods and set it via the args. If the routing table is statically set, all pods in this Flow will not send the routing table in the data requests and just use their own static routing table.

This does not work with external Pods as we cant set the routing table via args there.

If we want to make this feature work with external Pods as well, we would need to implement some mechanism to distribute the routing table outside of data requests. That might be desirable soon, but I think at this point it is better and safer to do this rather minimal change, which will only do exactly what we need now.

[github-actions]

Latency summary

Current PR yields:

• 🐢🐢 index QPS at 1169, delta to last 2 avg.: -14%
• 😶 query QPS at 34, delta to last 2 avg.: +1%
• 😶 dam extend QPS at 38156, delta to last 2 avg.: -17%
• 😶 avg flow time within 1.9265 seconds, delta to last 2 avg.: +0%
• 🐎🐎🐎🐎 import jina within 0.394 seconds, delta to last 2 avg.: +15%

Breakdown

Version	Index QPS	Query QPS	DAM Extend QPS	Avg Flow Time (s)	Import Time (s)
current	1169	34	38156	1.9265	0.394
2.0.19	1303	39	43533	1.9394	0.3689
2.0.18	1419	27	48669	1.9179	0.3149

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

[codecov]

Codecov Report

Merging #3222 (1e2711f) into master (83f6005) will increase coverage by 0.12%.
The diff coverage is 93.97%.

@@            Coverage Diff             @@
##           master    #3222      +/-   ##
==========================================
+ Coverage   90.33%   90.46%   +0.12%     
==========================================
  Files         148      148              
  Lines       10297    10346      +49     
==========================================
+ Hits         9302     9359      +57     
+ Misses        995      987       -8     

Flag	Coverage Δ
daemon	42.84% <36.14%> (-0.01%)	⬇️
jina	90.45% <93.97%> (+0.12%)	⬆️

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

Impacted Files	Coverage Δ
jina/peapods/pods/__init__.py	86.70% <80.00%> (+0.08%)	⬆️
jina/peapods/grpc/__init__.py	91.30% <87.50%> (-0.06%)	⬇️
jina/flow/base.py	89.21% <100.00%> (+0.19%)	⬆️
jina/parsers/flow.py	100.00% <100.00%> (ø)
jina/parsers/peapods/base.py	100.00% <100.00%> (ø)
jina/peapods/runtimes/grpc/__init__.py	94.40% <100.00%> (+5.01%)	⬆️
jina/peapods/runtimes/zmq/zed.py	93.87% <100.00%> (+0.03%)	⬆️
jina/peapods/zmq/__init__.py	89.04% <100.00%> (+0.15%)	⬆️
jina/proto/serializer.py	100.00% <100.00%> (ø)
jina/types/message/__init__.py	87.37% <100.00%> (ø)
... and 4 more

---

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 83f6005...1e2711f. Read the comment docs.

[JoanFM]

Did not think it through much, but doesn't it seem that we are using 2 arguments that are not compatible to activate only one feature? it seems we are using 2 bits to provide 1 bit of info?

[JoanFM]

Are we sure if static routing table, that num_part will always be properly populated?

[jacobowitz]

I think so. At least for all non shared Pods (non external/regular) we know the information beforehand. For head peas it should be derived from needs and for tail peas it should be derived from parallel. As far as I can see it should be correct. But it might be worth adding more tests checking this, that is true

[jacobowitz]

Actually it did not work for the parallell case because the pea args were not updated after the Flow had set the Pod args. I fixed this and added tests for this case.

[jacobowitz]

I used two arguments, because on argument is a Flow global argument which defined 'this flow uses static routing tables' and the other args is defining per pod if it should send the routing table or not. At the moment the second argument is always automatically populated by the Flow depending on its configuration.
In the current implementation this might be unnecessary, but I think we might soon have a situation where pods within the same Flow do this differently (external/not external). It makes it easier to implement then if you dont have to change args. But of course one could also argue that we should only introduce this as needed later then.

[jacobowitz]

I've added another optimization for grpc and static routing table: The target pods cant change so they are pre computed in init