Add deferrable param in EmrContainerSensor

[pankajastro]

Add the deferrable param in EmrContainerSensor.
This will allow running EmrContainerSensor in an async way
that means we only submit a job from the worker to run a job
then defer to the trigger for polling and wait for a job the job status
and the worker slot won't be occupied for the whole period of
task execution.

---

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

[syedahsn]

Looks good! Just a few minor comments.

[dstandish]

Though I have seen it elsewhere, to me, putting "max_attempts" as a trigger parameter doesn't make sense.

The "right" way to set a time limit on a trigger is the deferral timeout. IMO, if an existing operator has max_attempts param, then we should just calculate the deferral timeout based on that number and use that.

This avoids the added complexity in the trigger, the extra signature param, and it avoids the odd fact that, if max attempts is used, then if a triggerer dies and the trigger is picked up again on another machine, it will start from zero and then get killed by the timeout anyway.

What do you think about this @pankajastro ?

[pankajastro]

This is a good point. thank you for raising it.

honestly, I didn't think about the possibility that a trigger can restart while writing this. I'll fix this.

[syedahsn]

This was a point that was brought up in a previous PR (by @dstandish :D), and the solution we went with was to essentially use both. Set a timeout on the operator level that is computed from the given parameters (as well as a 60 second buffer), but also use the number of attempts as a metric. I think it is beneficial to have the number of attempts used as a metric in the Triggers, but it is definitely a good idea to have the timeout set on the operator level in case of a Trigger restart, as mentioned above.

[pankajastro]

Adeed the timeout while deferring to handle

if a triggerer dies and the trigger is picked up again on another machine

removed max_attempt to reduce the code maintenance