Exploring possibility of moving DagAttributeTypes to execution API spec

[amoghrajesh]

---

Was generative AI tooling used to co-author this PR?

• No

Ok hear me out, this might be odd, but since its just one enum it didn't feel too wrong.

Instead of creating a shared library or duplicating the enum, we expose DagAttributeTypes through the Execution API's OpenAPI schema. This allows the Task SDK to get the enum values via code generation, keeping SDK and core serialization protocol in sync automatically.

Why this approach:

• SDK only needs 2 values (OP, TASK_GROUP) from the 30+ value DagAttributeTypes enum
• Adding a shared library felt heavyweight for just 2 string constants
• Hardcoding risked typos whcih could lead to broken contract
• OpenAPI schema generation provides automatic sync mechanism

The DagAttributeTypes enum is added to get_extra_schemas() and exposed in the API spec. When task-sdk regenerates its models, it gets a properly typed enum that matches what core expects for serialize_for_task_group()

Trade-off: This enum isn't actually used in API requests/responses - it's purely for the serialization. However, since we already generate SDK models from the API spec and need these exact values there, reusing the generation mechanism felt pragmatic.

I considered the alternative of creating shared/serialization library but it deemed overkill for 2 values used in few places.

---

• 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.

[amoghrajesh]

@uranusjr could i request a re review on this one?