### Apache Airflow version

2.5.1

### What happened

DagRun state and start_date are reset if somebody is clearing a task of the running DagRun.

### What you think should happen instead

I think we should not reset DagRun `state` and `start_date` in it's in the running or queued states because it doesn't make any sense for me. `state` and `start_date` of the DgRun should remain the same in case somebody's clearing a task of the running DagRun

### How to reproduce

Let's say we have a Dag with 2 tasks in it - short one and the long one:
```
dag = DAG(
    'dummy-dag',
    schedule_interval='@once',
    catchup=False,
)

DagContext.push_context_managed_dag(dag)

bash_success = BashOperator(
    task_id='bash-success',
    bash_command='echo "Start and finish"; exit 0',
    retries=0,
)

date_ind_success = BashOperator(
    task_id='bash-long-success',
    bash_command='echo "Start and finish"; sleep 300; exit 0',
)
```

Let's day we have a running Dagrun of this DAG. First task finishes in a second and the long one is still running. We have a start_date and duration set and the Dagrun is still running. It runs for example for a 30 secs (pic 1 and 2)

<img width="486" alt="image" src="https://user-images.githubusercontent.com/23456894/225335210-c2223ad1-771b-459d-b8ed-8f0aacb9b890.png">
<img width="492" alt="image" src="https://user-images.githubusercontent.com/23456894/225335272-ad737aef-2051-4e27-ae36-38c76d720c95.png">

Then we are clearing the short task. It causes clear of the Dagrun state (to `queued`) and clears `start_date` like we have a new Dagrun (pic 3 and 4)
<img width="407" alt="image" src="https://user-images.githubusercontent.com/23456894/225335397-6c7e0df7-a26a-46ed-8eaa-56ff928fc01a.png">
<img width="498" alt="image" src="https://user-images.githubusercontent.com/23456894/225335491-4d6a860a-e923-4878-b212-a6ccb4b590a3.png">

### Operating System

Unix/MacOS

### Versions of Apache Airflow Providers

_No response_

### Deployment

Official Apache Airflow Helm Chart

### Deployment details

_No response_

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

self,
        verbose: bool = True,
        ignore_all_deps: bool = False,
        ignore_depends_on_past: bool = False,
        wait_for_past_depends_before_skipping: bool = False,
        ignore_task_deps: bool = False,
        ignore_ti_state: bool = False,
        mark_success: bool = False,
        test_mode: bool = False,
        job_id: str | None = None,
        pool: str | None = None,
        external_executor_id: str | None = None,
        session: Session = NEW_SESSION,
    ) -> bool:
        """
        Checks dependencies and then sets state to RUNNING if they are met. Returns
        True if and only if state is set to RUNNING, which implies that task should be
        executed, in preparation for _run_raw_task
        :param verbose: whether to turn on more verbose logging
        :param ignore_all_deps: Ignore all of the non-critical dependencies, just runs
        :param ignore_depends_on_past: Ignore depends_on_past DAG attribute
        :param wait_for_past_depends_before_skipping: Wait for past depends before mark the ti as skipped
        :param ignore_task_deps: Don't check the dependencies of this TaskInstance's task
        :param ignore_ti_state: Disregards previous task instance state
        :param mark_success: Don't run the task, mark its state as success
        :param test_mode: Doesn't record success or failure in the DB
        :param job_id: Job (BackfillJob / LocalTaskJob / SchedulerJob) ID
        :param pool: specifies the pool to use to run the task instance
        :param external_executor_id: The identifier of the celery executor
        :param session: SQLAlchemy ORM Session