Clean up top-level SDK imports in Core

[uranusjr]

Some more cleanups

1. The airflow.utils.context module has been cleaned up. Old names are redirected to airflow.sdk with a warning.
2. from airflow.utils.context import Context for typing (mostly in providers) are all unconditionally changed to from airflow.sdk import Context since they should only matter for our Mypy checks in CI.
3. A compat layer is made in devel-commons for imports of Context in provider tests.
4. SDK imports to keep old Core functions working are now made locally instead.

Most of the Core modules are now SDK-free (aside from typing). Exceptions are

• Partitions
• DeadlineAlert
• Template-rendering things

The two are on old as mentioned in #52141. I plan to tackle the third next. That’s a bit complicated.

[potiuk]

Should not we use "compat" also for type checking?

I think not having compat will make mypy and other typing checks confused if our users will use mypy for checking their dags in Airflow 2 - we had a number of issues in the past from our users when they had some problems with it.

As far as I understand how MyPy and other type checkers work, is that they actually parse even installed packages - so if someone installs our provider and runs mypy checks on their code using that provider, the if TYPE_CHECKING branch will be triggered, and if they do it in Airflow 2 - that will yield "unknown import" - which at the worst case will trigger typing check error that they will have to # type: ignore, at the best case the inference for those types won't work and their mypy checks are not going to be as useful.

So for me - the decision to not use compat for TYPE_CHECKING branches has some negative effects for Airlfow 2 users - and I don't see what we are going to gain by doing it (We will have to anyhow convert those into sdk imports in bulk when we go to apache-airflow>=3.1.0 state for providers).

[uranusjr]

Type checking can have compatibility, the specific pattern I changed here does not affect that. from airflow.sdk import Context only affects typing in that module (users shouldn’t do e.g. from airflow.providers.imap.sensors.imap_attachment import Context in any circumstance), and user-side typing does not consider third-party modules. Chaning these imports only affects type-checking on our side (in CI, during Airflow development, etc), not users.

[potiuk]

Type checking can have compatibility, the specific pattern I changed here does not affect that.

Agreed! Indeed if someone uses Context from one of those, they deserve to have an error that they should fix :)