promote empty chunk tolerance param into ChatCompletionClient

[MohMaz]

Why are these changes needed?

The max_consecutive_empty_chunk_tolerance param was implemented for open ai client, this PR properly promotes it to the ChatCompletionClient protocol to enforce it to all of the implementations.

Didn't update the docs as another contributor is helping with the updates.

Related issue number

Related #5078

Checks

• I've included any doc changes needed for https://microsoft.github.io/autogen/. See https://microsoft.github.io/autogen/docs/Contribute#documentation to build and test documentation locally.
• I've added tests (if relevant) corresponding to the changes introduced in this PR.
• I've made sure all auto checks have passed.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 70.08%. Comparing base (8428462) to head (7f49048).

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #5210   +/-   ##
=======================================
  Coverage   70.08%   70.08%           
=======================================
  Files         179      179           
  Lines       11619    11619           
=======================================
  Hits         8143     8143           
  Misses       3476     3476           

Flag	Coverage Δ
unittests	70.08% <ø> (ø)

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

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[ekzhu]

Do we need to have this or is it to address the peculiarity of open AI API.

[MohMaz]

Do we need to have this or is it to address the peculiarity of open AI API.

This was just for the OpenAI, and my understanding of this message was that we need to make this fix first. I personally lean towards making sure all of the implementations of ChatCompletionClient have exact same signature.

[ekzhu]

Won't other new model clients such as Ollama and Azure AI will have their own version of keyword arguments to address different types of issues? Generally we would like to keep the base class method as lean as possible.

[MohMaz]

Won't other new model clients such as Ollama and Azure AI will have their own version of keyword arguments to address different types of issues? Generally we would like to keep the base class method as lean as possible.

Makes sense and I agree. Maybe I misunderstood this message. If you can clarify, I can update/close this PR and do the next part of streaming integration with the UI.

[ekzhu]

Won't other new model clients such as Ollama and Azure AI will have their own version of keyword arguments to address different types of issues? Generally we would like to keep the base class method as lean as possible.

Makes sense and I agree. Maybe I misunderstood this message. If you can clarify, I can update/close this PR and do the next part of streaming integration with the UI.

Sorry for the confusion. I meant the keyword arguments should go after a * in the base class's abstract method.