Improve default llm retry logic to be more optimized

[jgbradley1]

Description

This PR makes changes to provide a more optimized retry logic for graphrag by default. It also simplifies the configuration by removing config variables that do not provide much value.

Proposed Changes

There are two significant behavioral changes to take note of (can be disabled if users don't wish to use it)

• switch to using max_retries in the openai library
• dynamically set the value of max_retries in each step of the indexing pipeline based on the input dataset size

As default behavior, these changes will cause graphrag's retry-logic to utilize the response back from OpenAI to determine how long to wait until it retries an LLM call (i.e. server-side retry logic), as opposed to retry logic that is based on the client-side only. This is done by calculating optimal values for the max_retries parameter when instantiating an openai client. Note that the openai library now has support for the retry-after header (providing a more accurate estimate of time to wait between LLM calls)...so if graphrag bases its' retry-logic entirely on the openai library, this approach should allow us to achieve full quota utilization with fewer configuration variables needed by graphrag.

For users that don't want to use the dynamic retry logic, it can be disabled and other retry-logic is exposed in the configuration file (tokens_per_minute and requests_per_minute).

This dynamic retry logic was tested on two separate AOAI models, with 10K TPM and 400K TPM, to evaluate effectiveness. I also tested across different dataset sizes as well and did not any experience errors due to graphrag reaching the max number of retries for an LLM call.

Checklist

• I have tested these changes locally.
• I have reviewed the code changes.
• I have updated the documentation (if necessary).
• I have added appropriate unit tests (if applicable).

Additional Notes

[Add any additional notes or context that may be helpful for the reviewer(s).]