Bring back support for local dagbag based list/list-import-errors

[dheerajturaga]

Airflow 2 supported running of airflow dags list and airflow dags list-import-errors without bringing up other services (webserver/scheduler/dag-processor/triggerer) However, in Airflow 3, airflow dags list and airflow dags list-import-errors fetch from the database instead.

This requires dag developers to have a dag-processor service running on their local setups for these simple tasks (for example: some one trying make quick dag changes and commit to their dag repository)

We need to keep the ability to list dags and import errors without having to run any other services. This PR addresses this issue by introducing a --local argument to airflow dags list and airflow dags list-import-errors.

This command will fetch from db: airflow dags list
This command will read the local dagbag instead: airflow dags list --local

Resolves #49330

Closes #49331

[jscheffl]

Note during review:
When just installing current branch via UV into my local venv, still when using the --local mode it asks me to create a DB - is this intended?

(airflow) jscheffl@hp860g9:~/Workspace/airflow$ airflow dags list --local

Please confirm database initialize (or wait 4 seconds to skip it). Are you sure? [y/N]
y
[2025-04-20T20:15:49.390+0200] {migration.py:207} INFO - Context impl SQLiteImpl.
[2025-04-20T20:15:49.392+0200] {migration.py:210} INFO - Will assume non-transactional DDL.
[2025-04-20T20:15:49.393+0200] {db.py:729} INFO - Creating Airflow database tables from the ORM
[2025-04-20T20:15:49.815+0200] {migration.py:207} INFO - Context impl SQLiteImpl.
[2025-04-20T20:15:49.815+0200] {migration.py:210} INFO - Will assume non-transactional DDL.
[2025-04-20T20:15:49.827+0200] {migration.py:618} INFO - Running stamp_revision  -> 29ce7909c52b
[2025-04-20T20:15:49.832+0200] {db.py:740} INFO - Airflow database tables created
DB initialize done

[dheerajturaga]

@jscheffl , yes
Its similar to the behavior in 2.10*
I think the provider_session triggers the db initialization

[jscheffl]

In general I support the idea using the commands to check if local edited DAG files are parse-able.
Otherwise I am asking a bit myself if it would be better to introduce a specific command for this like airflow dags parse which would just print errors if un-parsable?

Following on this would be cool to offer a "pre-commit" that people can just add to their repo (if not existing already?) based on this.

Before merging would like another opinion, as on the bug report there had been some discussions already, e.g. by @bugraoz93 ?

[bugraoz93]

@jscheffl Thanks! I agree. It's all good to include this in the code base. I was clarifying some things for AF 3 in the issue. I wasn't against the idea.
I tried to understand the scenario better, and my only concern with the approach was this action command calling and action command, which is addressed in this PR :)
#49331 (comment)

Looks good! @dheerajturaga, thanks for adding and addressing the comment! :)

[dheerajturaga]

Thanks @jscheffl & @bugraoz93 !!