Move Pod*Exceptions to separate module to avoid unnecessary slow imports in CLI

[IKholopov]

Pod*Exceptions has been moved from core to providers back in de92a81, but kept in airflow/exceptions.py under try-case for backwards compatibility and allow for usage of an older k8s provider with a newer core airflow.

This resulted in 2 unintended side-effects:

1. Any CLI command started taking ~ 1s longer to start. That is because importing anything from airflow resulted in importing kubernetes client. It is effectively the most expensive import out of all CLI does for any command, even though it is used by very few commands. Here are the timings of a trivial airflow dag-processor --help

• Before this PR: 6.0s https://pastebin.com/zb0QHFq9
• After this PR: 4.97s https://pastebin.com/QC5Rbyt5

2. Some time ago the compatibility import broke altogether. Because of the amount of imports in pod_generator.py, the import from exceptions.py failed even if providers were up to date with recursive import. But it was caught by exception handling, resulting in from airflow.exceptions import PodMutationHookException and from airflow.providers.cncf.kubernetes.pod_generator import PodMutationHookException pointing to different classes defeating the purpose of the fallback.

This PR addresses both by moving PodGenerator exceptions to the separate module that only import its base class. This keeps imports backwards compatible, doesn't attempt to load k8s modules and fixes the divergence of exception classes in airflow.providers.cncf.kubernetes.pod_generator and airflow.exceptions.

It is worth noting, that all usages of those exceptions in core Airflow also has been cleaned up since then, so if you believe that we need to remove those exceptions from airflow/exceptions.py, please let me know.

---

^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named {pr_number}.significant.rst or {issue_number}.significant.rst, in newsfragments.

[potiuk]

Nice one! Love the timing results

[potiuk]

I applied "full tests needed" and rebased it - I think that one should run full suite of tests due to potential compatibility issues.

[IKholopov]

Looks like the only failure is unrelated one (already failing on parent commit, same failure as here: #45727 (comment) - providers/tests/common/sql/hooks/test_dbapi.py::TestDbApiHook::test_run_no_log ).

[o-nikolas]

Ahh, I love these kinds of PRs :)

[potiuk]

Added an issue for the flaky stuff #45774

[potiuk]

It looks like another "caplog issue"