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

Variable.set(key="arg1", value=[1, 2])
    with dag:
        task_2.expand(arg2=task_1()).operator
    
    
    serialized_dag = SerializedDAG.from_dict(SerializedDAG.to_dict(dag))
    dr.dag = serialized_dag
    
    ti = dr.get_task_instance(task_id="task_1")
    task1 = dag.get_task("task_1")
    ti.refresh_from_task(task1)
    ti.run()
    
    dr.task_instance_scheduling_decisions()
    tis = dr.get_task_instances()
    indices = [(ti.map_index, ti.state) for ti in tis if ti.map_index >= 0]
    assert sorted(indices) == [
        (0, State.NONE),
        (1, State.NONE),
        (2, TaskInstanceState.REMOVED),
    ]
def test_mapped_literal_faulty_state_in_db(dag_maker, session):
    """
    This test tries to recreate a faulty state in the database and checks if we can recover from it.
    The state that happens is that there exists mapped task instances and the unmapped task instance.
    So we have instances with map_index [-1, 0, 1]. The -1 task instances should be removed in this case.
    """
    with dag_maker(session=session) as dag:
        @task
        def task_1():