Fix pyfunc bugs for release

[deadlycoconuts]

Context

This PR aims to include a couple of minor bug fixes and refactoring before the upcoming minor release of Turing:

• Renaming of the features keyword argument of the abstract ensemble method in EnsemblerBase of the SDK to input for less ambiguity when implementing Pyfunc ensemblers
• Transformation of the list of route responses in real-time ensembler requests to a dict of route responses indexed by route names in the SDK PyFunc interface, so as to improve usability and consistency of the predictions keyword argument of the aforementioned ensemble method
• Addition of a name search query to the Turing API endpoint for listing registered ensemblers, so as to resolve the non-functioning ensembler search bar in the Turing UI
• Fixing of e2e batch prediction tests due to the non-deterministic behaviour of the experiment engine
• (Temporary) downgrading of support for the Turing SDK, ensembler job engine and ensembler service engine to only Python 3.7.*. This is to align Turing with Merlin's support for Python of that particular minor version.

[krithika369]

Left some small comments. LGTM, pending the discussion about the e2e test case. Thank you!

[deadlycoconuts]

@romanwozniak https://github.com/gojek/turing/runs/5715592714?check_suite_focus=true#step:18:78 🥲 I'll go look at it again and see what went wrong.

[romanwozniak]

@romanwozniak https://github.com/gojek/turing/runs/5715592714?check_suite_focus=true#step:18:78 🥲 I'll go look at it again and see what went wrong.

I have only two assumptions:

• "hash/fnv" hashing is non-deterministic (I doubt that)
• There is something wrong with the /batch_predict endpoint – i.e. response from one prediction request in the batch is being assigned to the wrong request before marshaling
  This is the raw response, so the issue has nothing to do with the JSON comparison

01_create_router_test.go:84: Response Payload:
        [{"code":200,"data":{"request":{"client":{"id":4}},"response":{"route_responses":[{"route":"control","data":{"version":"control"},"is_default":true}],"experiment":{"configuration":{"foo":"bar"}}}}},{"code":200,"data":{"request":{"client":{"id":7}},"response":{"route_responses":[{"route":"control","data":{"version":"control"},"is_default":true}],"experiment":{"configuration":{"foo":"bar"}}}}}]

You probably can merge this MR and keep the fix to the E2E test out of scope for now

[romanwozniak]

@deadlycoconuts actually, it's neither nor. I can reproduce the issue by running the unit test ( which I added recently) multiple times. However, the hashing is consistent. It could be related to the floating-point precision or something similar. Let me try to figure it out

[deadlycoconuts]

Thanks a lot for your help for the time being @romanwozniak !

[romanwozniak]

Thanks a lot for your help for the time being @romanwozniak !

TIL: range operation over map is not deterministic: https://go.dev/blog/maps

[romanwozniak]

Thanks a lot for your help for the time being @romanwozniak !

@deadlycoconuts It's fixed now. Sorry, for hijacking your PR. The diff is here:
https://github.com/gojek/turing/pull/188/files/481c6933929dbea18854ad9ebab07a1b3ba6e612..808818c4285983ef243ab6612545b4fff91e51a0

[deadlycoconuts]

Haha no worries, thanks a lot for digging into and solving the mystery of this really elusive bug! 😂

[deadlycoconuts]

Okay I'll be merging this if there aren't anything outstanding left! Thanks a lot everyone for your input! 🚀