Add retry logic to BigQueryInsertJobOperator for 429 error

[Crowiant]

If a user does not set a job_id and the BigQueryInsertJobOperator fails with a 429 error, the current retry logic will not work. This is because the operator automatically generates the exact same job_id on every retry, which triggers an AirflowException: 'Job already reached DONE state'.

Retry Logic added by this PR:

Note: The job_id should not be manually set by the user.

Attempt 1: The operator will create a BigQuery job using the provided configuration and a job_id generated internally by the operator. If the job finishes in a DONE state but with a "429 Too many requests" error in error_result, the task will fail.

Attempt 2: The operator will generate the same job_id and submit it to the BigQuery service, which will return a Conflict error. The operator will check if the previous job's state is DONE and if its error_result contains the 429 error. If it does, a new job_id will be generated with the try_number appended to the end, and the job will be resubmitted and executed. This logic also allows the task to reattach to an existing BigQuery job in the case of an Airflow component failure.

---

Was generative AI tooling used to co-author this PR?

• Yes (please specify the tool below)

---

• Read the Pull Request Guidelines for more information. Note: commit author/co-author name and email in commits become permanently public when merged.
• For fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
• When adding dependency, check compliance with the ASF 3rd Party License Policy.
• For significant user-facing changes create newsfragment: {pr_number}.significant.rst, in airflow-core/newsfragments. You can add this file in a follow-up commit after the PR is created so you know the PR number.

[kevinhongzl]

Nice! Looking good overall.