api: Add auto_retry_rate_limits option to Client to handle 429 errors

[sohampanda000]

My Pull Request (PR) adds the boolean auto_retry_rate_limits as a parameter in the Client class in __init__.py of the Python Zulip API.

Fixes:

• Python's API Library does not handle HTTP 429 (RATE_LIMIT_HIT) errors automatically. If a client exceeds the message limit, Python will throw an error and forces users to manually implement a method to pause the thread and try again.

• To resolve this, the __init__ constructor of the Client class has been given a new addition of an opt-in parameter initialized to False to keep existing behavior. This catches the 429 status code in this function: do_api_query().

• So, it is ensured that the client safely parses the retry-after value, pauses the sleep thread using the time.sleep() function, and finally tries the message request again without failure.

How changes were tested:

• Continuous Pipeline (CI) Testing: I pushed the commit, via git push, to trigger the GitHub Actions CI Suite. This commit sustains the code through standard API testing suits. Additionally, the zulint linter checks Python formatting and that no client configurations have broke.

• Testing Verification: After verifying everything, I made sure of the try/catch code block for parsing retry-after defaults to 1 seconds only if the JSON (body or header) is unusual at all.

Self-review checklist

• Self-reviewed the changes for clarity and maintainability
  (variable names, code reuse, readability, etc.).

Communicate decisions, questions, and potential concerns.

• Explains differences from previous plans (e.g., issue description).
• Highlights technical choices and bugs encountered.
• Calls out remaining decisions and concerns.
• Automated tests verify logic where appropriate.

Individual commits are ready for review (see commit discipline).

• Each commit is a coherent idea.
• Commit message(s) explain reasoning and motivation for changes.

Completed manual review and testing of the following:

• Visual appearance of the changes.
• Responsiveness and internationalization.
• Strings and tooltips.
• End-to-end functionality of buttons, interactions and flows.
• Corner cases, error conditions, and easily imagined bugs.

Refer to Issue #773 for further information.

[alya]

Thanks! Please go through our guide on submitting a pull request to learn how to present your proposed changes to Zulip, so that your work can be reviewed.

[sohampanda000]

Alya, thank you for the pointer! I updated this PR to follow Zulip's commit discipline by rebasing everything into one commit.

[sohampanda000]

@alya could you check this PR?