AIP-72: Handling failed TI state for AirflowFailException & AirflowSensorTimeout

[amoghrajesh]

related: #44414

We already have support for handling terminal states from the task execution side as well as the task SDK client side. (almost) and failed state is part of the terminal state.

This PR extends the task runner's run function to handle cases when we have to fail a task: AirflowFailException, AirflowSensorTimeout. It is functionally very similar to #44786

As part of failing a task, multiple other things also needs to be done like:

• Callbacks: which will eventually be converted to teardown tasks
• Retries: Handled in Handle Task retries in Task SDK #44351
• unmapping TIs: Handle Task retries in Task SDK #44351
• Handling task history: will be handled by Handle Task instance history from task SDK #44952
• Handling downstream tasks and non teardown tasks: will be handled by Handle fail_stop / non teardown tasks in TASK SDK #44951

Testing performed

End to End with Postman

1. Run airflow with breeze and run any DAG
   

2. Login to metadata DB and get the "id" for your task instance from TI table
   

3. Send a request to fail your task
   

Or using curl:

curl --location --request PATCH 'http://localhost:29091/execution/task-instances/0193cec2-f46b-7348-9c27-9869d835dc7b/state' \
--header 'Content-Type: application/json' \
--data '{
    "state": "failed",
    "end_date": "2024-10-31T12:00:00Z"
}'

4. Refresh back the Airflow UI to see that the task is in failed state.
   

---

^ 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 newsfragments.