Unfortunately, external task sensors reference "execution date" quite
extensively, and even include it as a part of its public API (both that
exact variable, and things like execution_offset and excution_date_fn).
It is definitely possible to migrate them to something else, but it is
some substential work, and I actually suspect these aren't used widely,
if by anyone at all, since we did not receive a single report pointing
out those are currently emitting DeprecationWarning messages from core
Airflow code. So I'm going to leave the public interface alone for now,
and only change the internals to not emit warnings.

Similar to ExternalTaskSensor, the execution date terminology is
unfortunately a part of its public API. This one is easier to deprecate,
but again, it's entirely unclear how many people are actually using
this, especially now we have async triggers. So I'm leaving the
interface alone.

Again, execution date is unfortunately a part of the operator's public
interface. But again, better to leave it again. 🤷

Where we actually want to make sure those arguments work properly.

To avoid deprecated context variables emitting warnings, we must call
determine_kwargs directly on the context mapping first, instead of using
the make_kwargs_callable wrapper, which uses **kwargs and eagerly access
all the members.

Similar to other Jinja rendering situations, we can't just pass
**context into Template.render().

Similar to DayOfWeekSensor and BranchDateTimeOperator, this also has
execution date in its public interface. But let's not deal with it now.

Same as the regular handler.

More of the same thing.

Due to how Python works, we can't make the keyword argument dict lazy,
and calling fn(**context) would emit deprecation warnings too eagerly.
The previous warning strategy with lazy-object-proxy is brought back for
this particular use case, and only deprecated entries are converted to
lazy proxies if the context is being unpacked, to keep possible
incompatibilities minimal.