Create Base Class for OpenAI based clients

Once this issue is ready to go, we would need to also create follow up tickets on every provider in order to clean up the openai-php/client library from them.

Great work - I added some comments. The one about api key being optional needs to be fixed, look at the other and see if you agree. The streamed message could be a follow up issue, if needed.

Lookgs good for me - one comment - Dan will have a look as well, since the Amazee are dependent on it.

Then let's wait until Dan review and test it.

Thanks to check it Marcus.

Looks great now - I'll set this in RTBC and merge tomorrow if Dan didn't have a look. I think this might be one of the issues where its easier to continue developing and finiding missing scope/bugs by having it already in 1.2.x-dev, so you can target that with the providers under development.

The upgrade path to this should be safe - the providers can't be updated without 1.2.0 of the AI module, and updating the AI module to 1.2.0, but keeping 1.1.0 providers is fine.

We've provided changes to the other issue / MR - https://www.drupal.org/node/3532631 →
https://git.drupalcode.org/project/ai_provider_amazeeio/-/merge_requests/15

So this MR should be good from our side.

No one complained in the AI Contrib meeting, so in it goes.

I think there is an issue with the implementation of \Drupal\ai\Base\OpenAiBasedProviderClientBase::canChatStream.

Currently it simply returns $this->streamed. That property is whether or not we want a streamed response, not whether it's supported (which is what both the method name and documentation the method should do).

In 📌 Support Fibers for collaborative multitasking on LLM io waiting Active we are using streaming as a proxy for async requests, which means we need to be able to know whether it's supported separately to whether it's requested for the API call.

Not sure whether we want the default to be TRUE or FALSE? Specific providers can then override.

Automatically closed - issue fixed for 2 weeks with no activity.

@andrewbelcher perhaps, we should default to FALSE? Providers should explicitly pass TRUE if they support it?

@andrewbelcher perhaps, we should default to FALSE? Providers should explicitly pass TRUE if they support it?