Integrate UiPath-LangChain-Client and cleanup old clients

[cosminacho]

This new client package has 2 main components:

1. uipath-llm-client

• this is the core package on which uipath-langchain-client depends
• it handles URL, headers and authentification for both AgentHub and LLMGateway
• Encapsulates all the auth settings as well as retries, custom exceptions, byo stuff, custom headers for streaming etc into an httx.Client
• it also has passthrough httpx clients for providers like openai, anthropic, gemini (using their clients)
• can be added with: uv add "uipath-llm-client[openai, google, all]" etc. Without specifying extra dependencies it installs only the main httpx client that does the url, headers and auth stuff

2. uipath-langchain-client

• uses the httpx client from uipath-llm-client
• the passthrough implementations are minimal, all passthrough clients use a httpx client to make requests, we can just use the httpx client created above and inject it in the langchain-client for that vendor
• it also has a factory method which does a GET on the discovery endpoint and correctly instantiates the appropiate passthrough client for that model_name and the vendor detected

Summary of the Changes for this package:

• Retrying moved to the uipath-langchain-client
• Request Mixin removed because it’s on the uipath-langchain-client now as UiPathBaseLLMClient
• Streaming fixes added to uipath-langchain-client
• Auth headers, url creation and refresh token with uipath auth moved to uipath-langchain-client
• All clients implement UiPathBaseLLMCLient which has api_config from where we can get vendor_type and api_flavor
• tool_choice=“any” works for any provider if you use bind_tools() which should be used. bind() just adds the “any” parameter to the request body, it doesn’t map it to the correct tool_choice format for that provider
• Retryers are handled in uipath-langchain-client at transport level on the httpx client, so no need to hardcode for each provider
• Factory is now in uipath-langchain-client (and it uses the discovery endpoint)
• Gemini streaming fixes moved
• Comprehensive tests are in the package, we can remove them from here
• Also the normalized client is in the new client

Before merging this PR I think it's important to make sure that all the relevant components have been moved to the new client, and also that the new changes aren't breaking stuff that's working

Still WIP, but maybe not necessary for this merge:

• merging generation info with response metadata on gemini? (i need to test it to see what's the problem, and add the fix there)
• on Bedrock: Convert file_blocks_to_anthropic_documents: to test if it's really working without it. But in anycase, I think it's better to use UiPathChatAnthropic instead of the BedRock Client. I will test this functionality with both to see the differences.

Some personal recommendations:

• I think for anthropic it's better to use UiPathChatAnthropic(model="etc", provider_type="vertexai"/"bedrock"), instead of doing the Bedrock clients. Why? Because UiPathChatAnthropic has the latest features that anthropic releases on new models, and in it's implementation uses specific http clients for each provider (also maintained by them). So I think it's better to trust the model provider that it keeps the api in sync, and not AWS which hosts a 1000 different models on the same API

[ionut-mihalache-uipath]

What is the purpose of this file? My concerns:

• when a new model appears we want to make it available in prod in the same day. This would require a new deployment.
• when a client uses Bring Your Own model, they can name their models however they want, like MyCustomModel. We should not do any validations based on model name. We should also remove all the "Invalid model name" exceptions from uipath_langchain_client: https://github.com/UiPath/uipath-llm-client-python/blob/287ca44d28ed09d6c1786508dacef9958c43d4fb/packages/uipath_langchain_client/src/uipath_langchain_client/factory.py#L106

[cosminacho]

I agree, I don't think this file is necessary, but I left it untouched because as I understood from @andrei-rusu, there might be some people who use it, and I think he uses it in the gym. But I personally like more the factory method with the discovery endpoint because it makes the package available when a new model appears.

[cosminacho]

And yes, I can refactor as well the factory from uipath_langchain_client

[ionut-mihalache-uipath]

The discovery API returns the API Flavors that a model supports. Some clients with BYO do support only one API flavor, for example just bedrock converse or just bedrock invoke. I don't see where the API Flavor returned by the LLMGw on the discovery API is taking into account when instantiating the LLM client.

I see that for bedrock api_config.api_flavor is always set to "invoke" (in uipath_langchain_client), which I think is wrong.

[ionut-mihalache-uipath]

I think you should increase the major version of uipath-langchain-python as it is not backwards compatible. Some methods used in uipath-agents-python are removed.