Sync airflowctl from main to v3-1-test to include all changes in integration tests

[bugraoz93]

related: #56986
After the related PR is merged because integration tests need one-line backport, which I couldn't do here. This will be the last PR before release, and I will create the tag after merging this one as well as RC voting :)

---

^ 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 airflow-core/newsfragments.

[bugraoz93]

Marking as draft until the related is merged. I will include one more line due to we have some differences in integration tests.

[ashb]

I'm unsuer as to why we need changes for airflowctl on the v3-1 branches? That's just for apache-airflow-core and apache-airflow-task-sdk releases, and airflowctl is independent of Airflow versions/releases, isn't it?

[bugraoz93]

I'm unsuer as to why we need changes for airflowctl on the v3-1 branches? That's just for apache-airflow-core and apache-airflow-task-sdk releases, and airflowctl is independent of Airflow versions/releases, isn't it?

Great point Ash! The need for syncing this branch to v3-1 is to trigger integration tests for v3-1 because it uses the built prod image in the test that was created in the same workflow/pipeline. This will be v1.0.0 and we have planned to provide support for v3-1 for airflowctl but ended up a bit late than the v3-1 cut. We are running CI pipelines on a schedule for main and v-3-1. To stop syncing, we need to run the integration tests for all supported versions from main to provide a fully tested airflowctl version at time T in regular development and release cycles. I will plan this and make it possible for the next release cycles. This was a lot easier for the first iteration. Maybe a bit in more future, we may even split airflowctl CI and run in different schedules using a more decoupled approach