[AIRFLOW-6910] Fix kill_zombie method call

[mik-laj]

---

Issue link: AIRFLOW-6910

Make sure to mark the boxes below before creating PR: [x]

• Description above provides context of the change
• Commit message/PR title starts with [AIRFLOW-NNNN]. AIRFLOW-NNNN = JIRA ID^*
• Unit tests coverage for changes (not needed for documentation changes)
• Commits follow "How to write a good git commit message"
• Relevant documentation is updated including usage instructions.
• I will engage committers as explained in Contribution Workflow Example.

^* For document-only changes commit message can start with [AIRFLOW-XXXX].

---

In case of fundamental code change, 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 UPDATING.md.
Read the Pull Request Guidelines for more information.

[codecov-io]

Codecov Report

❗ No coverage uploaded for pull request base (master@d1a3424). Click here to learn what that means.
The diff coverage is 100%.

@@            Coverage Diff            @@
##             master    #7531   +/-   ##
=========================================
  Coverage          ?   86.23%           
=========================================
  Files             ?      896           
  Lines             ?    42638           
  Branches          ?        0           
=========================================
  Hits              ?    36768           
  Misses            ?     5870           
  Partials          ?        0

Impacted Files	Coverage Δ
airflow/jobs/scheduler_job.py	87.69% <100%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update d1a3424...9933afe. Read the comment docs.

[Fokko]

Thanks @mik-laj

[ashb]

@mik-laj @Fokko In situations like this can we please get in to the habit of targeting the bug fix at the same Jira issue as the original breaking change -- that way if we ever need to backport it we get the change and the fix. Two jiras means the fix is likely to get missed.

(Plus right now one PR = one Jira is just busy work, if we're going to do this lets just stop using Jira)