[Inference] Implement a "1 class = 1 provider<>task pair" logic to isolate provider-specific code

[hanouticelina]

The Goal of this PR is to isolate provider-specific logic into its own class/file. Similar to what we have in the Python client, this gives a clear boundary between generic task implementation and provider-specific implementation details.

This makes updating or adding a new provider much easier, adding support for a new provider will be as much as easier as:

1. register the provider in the mapping.
2. create a new packages/inference/src/providers/{provider_name}.ts.
3. implement the methods that require custom handling.

Main changes

• Added a new TaskProviderHelper abstract class that defines a common interface (makeBody, preparePayload makeRoute, getResponse, prepareHeaders, etc.) that all provider-specific helpers must implement.
• Added PROVIDERS registry that maps any provider<>task to the corresponding TaskProviderHelper subclass that implements the provider<>task logic.
• Added a lookup function (getProviderHelper) that takes a provider and task and returns the appropriate TaskProviderHelper instance from the PROVIDERS registry.
• Implemented the task helpers for providers:
  • All task helpers have been implemented for all providers.

🙏 Any feedback is welcome as the implementation is quite biased towards the Python but we might want to do some things differently here.

[julien-c]

• create a new packages/inference/src/providers/{provider_name}.py.

i think you mean .ts, otherwise i'm a bit concerned by this PR 😆

[Wauplin]

Dunno where the "self-contained logic for each provider <> task"- idea comes from but I really like it! 😄

I tried to review the PR the best I can but hard to be exhaustive 😬 Overall very nice improvement

[SBrandeis]

This is a big PR - I would like to do some other rounds of review later to ensure I did not miss something :)

Great work overall - it will make contributing a provider much easier 💪

I'm a bit disappointed by the type narrowing (there is too much need for type casts to my taste) - especially when calling providerHelper.getResponse()

Perhaps we need an additional asbtract class per task to narrow down types in getProviderHelper..

I have left some comments on the form too (mostly code style)

[SBrandeis]

@hanouticelina I have opened #1332 with a proposal to improve the typing of getProviderHelper

Let me know what you think

[SBrandeis]

Let's go! 🚀

[Wauplin]

Let get this merged! 🎉

[hanouticelina]

merging!

[julien-c]

Woohoo! 🎉