### Apache Airflow version

2.2.3rc1 (release candidate)

### What happened

I ran a DAG that does nothing explicitly with context, so I'm surprised to see deprecation warnings about context being used (trimmed to cut down on noise):

```
baseoperator.py:1107 DeprecationWarning: Accessing 'execution_date' from the template is deprecated and will be removed in a future version. Please use 'data_interval_start' or 'logical_date' instead.
baseoperator.py:1107 DeprecationWarning: Accessing 'next_ds' from the template is deprecated and will be removed in a future version. Please use '{{ data_interval_end | ds }}' instead.
baseoperator.py:1107 DeprecationWarning: Accessing 'next_ds_nodash' from the template is deprecated and will be removed in a future version. Please use '{{ data_interval_end | ds_nodash }}' instead.
baseoperator.py:1107 DeprecationWarning: Accessing 'next_execution_date' from the template is deprecated and will be removed in a future version. Please use 'data_interval_end' instead.
baseoperator.py:1107 DeprecationWarning: Accessing 'prev_ds' from the template is deprecated and will be removed in a future version.
baseoperator.py:1107 DeprecationWarning: Accessing 'prev_ds_nodash' from the template is deprecated and will be removed in a future version.
baseoperator.py:1107 DeprecationWarning: Accessing 'prev_execution_date' from the template is deprecated and will be removed in a future version.
baseoperator.py:1107 DeprecationWarning: Accessing 'prev_execution_date_success' from the template is deprecated and will be removed in a future version. Please use 'prev_data_interval_start_success' instead.
baseoperator.py:1107 DeprecationWarning: Accessing 'tomorrow_ds' from the template is deprecated and will be removed in a future version.
baseoperator.py:1107 DeprecationWarning: Accessing 'tomorrow_ds_nodash' from the template is deprecated and will be removed in a future version.
baseoperator.py:1107 DeprecationWarning: Accessing 'yesterday_ds' from the template is deprecated and will be removed in a future version.
baseoperator.py:1107 DeprecationWarning: Accessing 'yesterday_ds_nodash' from the template is deprecated and will be removed in a future version.
```

### What you expected to happen

I'd only expect to see deprecation warnings about things my DAG is actually interacting with.

### How to reproduce

Run this DAG:

```python
from datetime import datetime

from airflow import DAG
from airflow.operators.bash import BashOperator

with DAG(
    dag_id="no-context", schedule_interval=None, start_date=datetime(2021, 12, 10)
) as dag:
    BashOperator(task_id="sleep", bash_command="echo 'Hello!'")
```

Note: I also tried a TaskFlow DAG and that wasn't impacted.

### Operating System

MacOS 11.6

### Versions of Apache Airflow Providers

_No response_

### Deployment

Virtualenv installation

### Deployment details

_No response_

### Anything else

This was introduced in #19886 (cc @uranusjr).

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

airflow/models/baseoperator.py
:type priority_weight: int
    :param weight_rule: weighting method used for the effective total
        priority weight of the task. Options are:
        ``{ downstream | upstream | absolute }`` default is ``downstream``
        When set to ``downstream`` the effective weight of the task is the
        aggregate sum of all downstream descendants. As a result, upstream
        tasks will have higher weight and will be scheduled more aggressively
        when using positive weight values. This is useful when you have
        multiple dag run instances and desire to have all upstream tasks to
        complete for all runs before each dag can continue processing
        downstream tasks. When set to ``upstream`` the effective weight is the
        aggregate sum of all upstream ancestors. This is the opposite where
        downstream tasks have higher weight and will be scheduled more
        aggressively when using positive weight values. This is useful when you
        have multiple dag run instances and prefer to have each dag complete
        before starting upstream tasks of other dags.  When set to
        ``absolute``, the effective weight is the exact ``priority_weight``
        specified without additional weighting. You may want to do this when
        you know exactly what priority weight each task should have.
        Additionally, when set to ``absolute``, there is bonus effect of
        significantly speeding up the task creation process as for very large
        DAGs. Options can be set as string or using the constants defined in
        the static class ``airflow.utils.WeightRule``
    :type weight_rule: str
    :param queue: which queue to target when running this job. Not
        all executors implement queue management, the CeleryExecutor
        does support targeting specific queues.
    :type queue: str
    :param pool: the slot pool this task should run in, slot pools are a
        way to limit concurrency for certain tasks