### 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)

if not self.client or not self.arn:
            return
        waiter = self.client.get_waiter("tasks_stopped")
        waiter.wait(
            cluster=self.cluster,
            tasks=[self.arn],
            WaiterConfig={
                "Delay": self.waiter_delay,
                "MaxAttempts": self.waiter_max_attempts,
            },
        )
    def _aws_logs_enabled(self):
        return self.awslogs_group and self.awslogs_stream_prefix
    def _get_logs_stream_name(self) -> str:
        return f"{self.awslogs_stream_prefix}/{self._get_ecs_task_id(self.arn)}"
    def _get_task_log_fetcher(self) -> AwsTaskLogFetcher:
        if not self.awslogs_group:
            raise ValueError("must specify awslogs_group to fetch task logs")
        return AwsTaskLogFetcher(
            aws_conn_id=self.aws_conn_id,
            region_name=self.awslogs_region,
            log_group=self.awslogs_group,
            log_stream_name=self._get_logs_stream_name(),
            fetch_interval=self.awslogs_fetch_interval,
            logger=self.log,
        )
    @AwsBaseHook.retry(should_retry_eni)
    def _check_success_task(self) -> None: