### Apache Airflow version

2.3.3 (latest released)

### What happened

I change my DAG from 
```python
with DAG(
   'test',
    access_control={'team':{'can_edit','can_read'}},
) as dag:
   ...
```

to

```python
with DAG(
   'test',
) as dag:
   ...
```

Remove `access_control` arguments, Scheduler can't sync permissions to db.

If we write code like this,

```python
with DAG(
   'test',
   access_control = {'team': {}}
) as dag:
   ...
```

It works.

### What you think should happen instead

It should clear permissions to `test` DAG on Role `team`.

I think we should give a consistent behaviour of permissions sync. If we give `access_control` argument, permissions assigned in Web will clear when we update DAG file.

### How to reproduce

_No response_

### Operating System

CentOS Linux release 7.9.2009 (Core)

### Versions of Apache Airflow Providers

```
airflow-code-editor==5.2.2
apache-airflow==2.3.3
apache-airflow-providers-celery==3.0.0
apache-airflow-providers-ftp==3.0.0
apache-airflow-providers-http==3.0.0
apache-airflow-providers-imap==3.0.0
apache-airflow-providers-microsoft-psrp==2.0.0
apache-airflow-providers-microsoft-winrm==3.0.0
apache-airflow-providers-mysql==3.0.0
apache-airflow-providers-redis==3.0.0
apache-airflow-providers-samba==4.0.0
apache-airflow-providers-sftp==3.0.0
apache-airflow-providers-sqlite==3.0.0
apache-airflow-providers-ssh==3.0.0
```

### Deployment

Virtualenv installation

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

"""Information about single file"""
    file: str
    duration: timedelta
    dag_num: int
    task_num: int
    dags: str
class DagBag(LoggingMixin):
    """
    A dagbag is a collection of dags, parsed out of a folder tree and has high
    level configuration settings, like what database to use as a backend and
    what executor to use to fire off tasks. This makes it easier to run
    distinct environments for say production and development, tests, or for
    different teams or security profiles. What would have been system level
    settings are now dagbag level so that one system can run multiple,
    independent settings sets.
    :param dag_folder: the folder to scan to find DAGs
    :param include_examples: whether to include the examples that ship
        with airflow or not
    :param read_dags_from_db: Read DAGs from DB if ``True`` is passed.
        If ``False`` DAGs are read from python files.
    :param load_op_links: Should the extra operator link be loaded via plugins when
        de-serializing the DAG? This flag is set to False in Scheduler so that Extra Operator links
        are not loaded to not run User code in Scheduler.
    """
    def __init__(