Document config-backed enum Dag Params

[fat-catTW]

Why

Dag authors sometimes need the choices for an enum Param to come from deployment-local
configuration rather than being hard-coded in the Dag file. Airflow already supports this —
the trigger form reads the serialized Param schema, so any list computed while the Dag is
parsed shows up as a dropdown — but nothing in the docs or the examples shows the pattern,
so it isn't obvious that it works.

What

Documents and demonstrates building an enum Param's choices from an external config file:

• params.rst notes that choices can be read from a config file at parse time, and that the
  trigger form uses the serialized Params rather than calling any dynamic choice provider
  when the form opens.
• example_params_ui_tutorial.py gains a script_interface Param whose choices come from a
  colocated INI file, filtered to the sections with TYPE = Script.
• example_params_ui_interfaces.ini is the accompanying config file.

No behavior change: enum Params still render as dropdowns, and no new schema fields or UI
code are added.

Scope

An earlier revision of this PR proposed an x-airflow-ui.widget = "radio" schema hint so
enum Params could render as radio buttons. That was dropped after review — the naming and
the expansion story for x-airflow-ui need to be settled first, and a radio has no way to
clear the selection for an optional Param. The dropdown already covers the "selector instead
of free text" ask in #56632, so this PR keeps to the documentation half.

related: #56632

Screenshot

Trigger Dag form showing the Script interface Param rendering as a dropdown with the
choices read from the INI file (Interface A, Interface C — InterfaceB is filtered out
because its TYPE is not Script):

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

• [X]` Yes (please specify the tool below)

Generated-by: [Codex] following the guidelines

---

• 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, in airflow-core/newsfragments. You can add this file in a follow-up commit after the PR is created so you know the PR number.

[bbovenzi]

I'm wary of adding a new x-airflow-ui option to declaring params. First the name isn't great. Second, we should define how we plan to expand this in the future.

Second, I am not sure if this closes the old issue because the person asked for a selector or a radio over plain text. I don't think it matters as much which of the two exist.

Third, the radio has no option to unselect when it is an optional param.

[fat-catTW]

Good afternoon.
Thanks for the review. I agree with the concerns here.

To clarify the current state of this PR:
The example demonstrates that a Dag author can read an INI file at Dag parse time, filter the available interfaces, and pass those values into a Param enum. Airflow Params currently expect the enum choices to be materialized when the Dag is parsed; the trigger form reads the serialized Param schema and does not have a generic "choices source" mechanism that can load/filter options when the form opens.

The trigger form already renders enum values as choices via the existing dropdown support, and this PR experiments with rendering the same enum values as radio buttons via x-airflow-ui. So this covers the “do not require free-text input” part, but it does not introduce a general dynamic choices provider or a reusable config-source mechanism.

I also agree that the selector vs radio part is secondary. The main missing design question is how Airflow should expose UI presentation preferences for Params in a way that can be extended later. The current x-airflow-ui key may be too ad hoc without that broader shape being defined.

Given that, I think there are two possible directions:

1. Keep this PR smaller and use the existing enum dropdown behavior, documenting the INI-at-parse-time pattern without adding a new UI extension key.
2. Expand this PR into a more deliberate Param UI presentation API, including how widgets such as dropdown/radio would be selected and how optional radio Params can be cleared.

I’m happy to take either direction. If maintainers think this PR should define the broader UI extension shape, I can work on that here; otherwise I can reduce this PR to the existing enum dropdown/docs pattern.

[bbovenzi]

Let's go with option 1. I think smaller PRs are always a better start and that gets to the core use-case.

[fat-catTW]

Thanks, I updated the PR to follow option 1.

The PR no longer adds x-airflow-ui or a radio widget path. It now keeps the existing enum dropdown behavior and documents/demonstrates the smaller pattern: read an external INI file while the Dag is parsed, filter the available choices, and pass the resulting list into a Param enum.

I also verified this manually in the UI with Params UI tutorial: the new Script interface field renders as a dropdown with Interface A and Interface C, while Interface B is excluded because it is not TYPE = Script.

[uros-b]

+1, thank you @fat-catTW!