Add async XCom accessors for async tasks

[dabla]

Related PR's

Related to:
#68214
#60268
#62922

Why

Async @task functions currently cannot efficiently pull or push XCom values because the existing xcom_pull and xcom_push implementations rely on synchronous communication with the task supervisor. Invoking these methods from an async task blocks the event loop, reducing the benefits of asynchronous execution.

This change introduces asynchronous XCom operations, allowing async Python tasks to interact with XComs without blocking the event loop.

This capability is also an important building block for the upcoming Task Iteration feature (AIP-104). Task Iteration relies on the ability to persist intermediate progress and results during execution, which requires non-blocking XCom operations when used with async tasks. As such, this PR serves as preparatory work for AIP-104 while also providing immediate value by enabling fully asynchronous XCom interactions in existing async Python tasks.

In addition, this functionality lays the groundwork for future async operators. As more operators adopt native async implementations, they will be able to leverage asynchronous XCom operations without blocking the event loop, enabling more efficient and scalable async execution patterns throughout Airflow.

How

• Add axcom_pull/axcom_push to RuntimeTaskInstance, awaiting the supervisor round-trip via asend instead of blocking.
• Add aget_one/aget_all/aset to BaseXCom for async XCom retrieval and storage.

---

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

• [ x ] Yes (please specify the tool below)

Claude Opus 4.6

---

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

[dabla]

Same here, it would be good if @ashb or @amoghrajesh could validate this PR.

[ashb]

Suggested change

	raise TypeError(f"Expected XComSequenceSliceResult, received: {type(msg)} {msg}")
	raise RuntimeError(f"Expected XComSequenceSliceResult, received: {type(msg)} {msg}")

IMO TypeError isn't quite right here, as this is more of a "omg we got the wrong response back!" than a type error, which is usuall more "you called this with the wrong type"

[ashb]

Suggested change

	return None
	return []

I think?