Add guardrail to handle DAG deserialization errors in scheduler

[vatsrahul1001]

Add try/except in _get_current_dag(). If deserialization fails, the scheduler logs the error and continues to the next DAG instead of crashing.

• Read the Pull Request Guidelines for more information. Note: commit author/co-author name and email in commits become permanently public when merged.
• For fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
• When adding dependency, check compliance with the ASF 3rd Party License Policy.
• For significant user-facing changes create newsfragment: {pr_number}.significant.rst or {issue_number}.significant.rst, in airflow-core/newsfragments.

[ashb]

Better than crashing the scheduler hard, though I wonder if will this continue to try and get it very loop around the scheduler leading to log spam and other knock on issues? Since the dag that is failing will still get returned in the DagModel.dags_needing_dagruns list (Ditto for anything asset related too?)

Not sure how best to address this...

[vatsrahul1001]

Better than crashing the scheduler hard, though I wonder if will this continue to try and get it very loop around the scheduler leading to log spam and other knock on issues? Since the dag that is failing will still get returned in the DagModel.dags_needing_dagruns list (Ditto for anything asset related too?)

Not sure how best to address this...

Maybe modifying dags_needing_dagruns query to exclude DAGs with certain warning types?