### Apache Airflow version

2.6.3

### What happened

When running multiple standalone DAG processors with separate DAG directories using the `--subdir` argument the processors keep deactivating each other's DAGs (and reactivating their own).

After stepping through the code with a debugger I think the issue is that the calls [here](https://github.com/apache/airflow/blob/2.6.3/airflow/dag_processing/manager.py#L794) and [here](https://github.com/apache/airflow/blob/2.6.3/airflow/dag_processing/manager.py#L798) have no awareness of the DAG directories.

### What you think should happen instead

The DAG processors should not touch each other's DAGs in the metadata DB.

### How to reproduce

Start two or more standalone DAG processors with separate DAG directories and observe (e.g. via the UI) how the list of active DAGs keeps changing constantly.

### Operating System

Linux 94b223524983 6.1.32-0-virt #1-Alpine SMP PREEMPT_DYNAMIC Mon, 05 Jun 2023 09:39:09 +0000 x86_64 x86_64 x86_64 GNU/Linux

### Versions of Apache Airflow Providers

_No response_

### Deployment

Other Docker-based deployment

### Deployment details

_No response_

### Anything else

_No response_

### Are you willing to submit PR?

- [ ] 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)

.join(
                DDRQ,
                and_(
                    DDRQ.dataset_id == DagScheduleDatasetReference.dataset_id,
                    DDRQ.target_dag_id == DagScheduleDatasetReference.dag_id,
                ),
                isouter=True,
            )
            .join(DatasetModel, DatasetModel.id == DagScheduleDatasetReference.dataset_id)
            .group_by(DagScheduleDatasetReference.dag_id)
            .where(DagScheduleDatasetReference.dag_id.in_(dag_ids))
        ).all()
    }
@functools.total_ordering
class DAG(LoggingMixin):
    """
    A dag (directed acyclic graph) is a collection of tasks with directional dependencies.
    A dag also has a schedule, a start date and an end date (optional).  For each schedule,
    (say daily or hourly), the DAG needs to run each individual tasks as their dependencies
    are met. Certain tasks have the property of depending on their own past, meaning that
    they can't run until their previous schedule (and upstream tasks) are completed.
    DAGs essentially act as namespaces for tasks. A task_id can only be
    added once to a DAG.
    Note that if you plan to use time zones all the dates provided should be pendulum
    dates. See :ref:`timezone_aware_dags`.
    .. versionadded:: 2.4
        The *schedule* argument to specify either time-based scheduling logic
        (timetable), or dataset-driven triggers.
    .. deprecated:: 2.4
        The arguments *schedule_interval* and *timetable*. Their functionalities