### Apache Airflow version

2.7.1

### What happened

Trying to test **EcsRunTaskOperator** in deferrable mode resulted in an unexpected error at the `_start_task()` step of the Operator's `execute` method. The return error log was 
`{standard_task_runner.py:104} ERROR - Failed to execute job 28 for task hello-world-defer (date value out of range; 77)`

After a lot of research to understand the `date value out of range` specific error, I found [this PR](https://github.com/apache/airflow/pull/33712) in which I found from the [change log](https://github.com/apache/airflow/pull/33712/files#diff-4dba25d07d7d8c4cb47ef85e814f123c9171072b240d605fffd59b29ee3b31eb) that the `waiter_max_attempts` was switched to `1000000 * 365 * 24 * 60 * 10`  (Which results in 1M years). This change cannot work properly with an internal Airflow date calculation, related to the Waiter's retries. 



### What you think should happen instead

Unfortunately, I haven't been able to track the error further but by changing to a lower limit of 100000 waiter_max_attempts it worked as expected. 

My suggestion would be to decrease the default value of **waiter_max_attempts**, maybe 1000000 (1M) retries is a valid number of retries. These results will set the default value of the expected running attempt time to 1000000 * 6 ~ 70days 

### How to reproduce

By keeping the default values of **EcsRunTaskOperator** while trying to use it in deferrable mode.

### Operating System

Debian

### Versions of Apache Airflow Providers

apache-airflow-providers-airbyte==3.3.2
apache-airflow-providers-amazon==8.7.1
apache-airflow-providers-celery==3.3.4
apache-airflow-providers-common-sql==1.7.2
apache-airflow-providers-docker==3.7.5
apache-airflow-providers-ftp==3.1.0
apache-airflow-providers-http==4.5.2
apache-airflow-providers-imap==3.3.0
apache-airflow-providers-postgres==5.6.1
apache-airflow-providers-redis==3.3.2
apache-airflow-providers-snowflake==4.4.2
apache-airflow-providers-sqlite==3.2.1


### Deployment

Other Docker-based deployment

### Deployment details

- Custom Deploy using ECS and Task Definition Services on EC2 for running AIrflow services. 
- Extending Base Airflow Image to run on each Container Service (_apache/airflow:latest-python3.11_)


### Anything else

_No response_

### Are you willing to submit PR?

- [X] Yes I am willing to submit a PR!

### Code of Conduct

- [X] I agree to follow this project's [Code of Conduct](https://github.com/apache/airflow/blob/main/CODE_OF_CONDUCT.md)

:param awslogs_group: the CloudWatch group where your ECS container logs are stored.
        Only required if you want logs to be shown in the Airflow UI after your job has
        finished.
    :param awslogs_region: the region in which your CloudWatch logs are stored.
        If None, this is the same as the `region` parameter. If that is also None,
        this is the default AWS region based on your connection settings.
    :param awslogs_stream_prefix: the stream prefix that is used for the CloudWatch logs.
        This is usually based on some custom name combined with the name of the container.
        Only required if you want logs to be shown in the Airflow UI after your job has
        finished.
    :param awslogs_fetch_interval: the interval that the ECS task log fetcher should wait
        in between each Cloudwatch logs fetches.
        If deferrable is set to True, that parameter is ignored and waiter_delay is used instead.
    :param quota_retry: Config if and how to retry the launch of a new ECS task, to handle
        transient errors.
    :param reattach: If set to True, will check if the task previously launched by the task_instance
        is already running. If so, the operator will attach to it instead of starting a new task.
        This is to avoid relaunching a new task when the connection drops between Airflow and ECS while
        the task is running (when the Airflow worker is restarted for example).
    :param number_logs_exception: Number of lines from the last Cloudwatch logs to return in the
        AirflowException if an ECS task is stopped (to receive Airflow alerts with the logs of what
        failed in the code running in ECS).
    :param wait_for_completion: If True, waits for creation of the cluster to complete. (default: True)
    :param waiter_delay: The amount of time in seconds to wait between attempts,
        if not set then the default waiter value will be used.
    :param waiter_max_attempts: The maximum number of attempts to be made,
        if not set then the default waiter value will be used.
    :param deferrable: If True, the operator will wait asynchronously for the job to complete.
        This implies waiting for completion. This mode requires aiobotocore module to be installed.
        (default: False)