chore: Comment 3.9 PY required CI checks

[EugeneTorap]

SUMMARY

Before remove 3.9 PY support and bump to 3.10 PY version in #24112 we need to comment 3.9 PY CI tests in github config file.

BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF

TESTING INSTRUCTIONS

ADDITIONAL INFORMATION

• Has associated issue:
• Required feature flags:
• Changes UI
• Includes DB Migration (follow approval process in SIP-59)
  • Migration is atomic, supports rollback & is backwards-compatible
  • Confirm DB migration upgrade and downgrade tested
  • Runtime estimates and downtime expectations provided
• Introduces new feature or API
• Removes existing feature or API

[john-bodley]

@EugeneTorap why not simply remove as opposed to comment out. Additionally why is line #74 commented out?

[mistercrunch]

We do want to keep these checks, I think what's unclear/confusing on your other PR is that you need to rebase. Messing around with GitHub actions and checks recently, I learned that:

• required checks are dictated by what's on the master (target) branch, not what's the .asf.yml in your branch/PR
• The check that get executed are defined by the GitHub actions in branch of the PR
• if new checks are required on master and your branch doesn't have the GH actions related to it, it will hold, in other words, you need to rebase
• if you want to remove/delete a check, you may need a no-op check, or you have to do it in two phases (remove the required check first, and once that's merged, then remove the check), I added one in .github/workflows/no-op.yml to work around that. That's still two phases with that approach (remove the check and add a no-op in the first PR, then remove the entry from no-op later)

Oh while I'm here:

• This one is pretty annoying - required checks, cannot really be conditional (using the if: clause in actions), which is a pain in the butt, say it should absolutely be required that say python unit tests pass CI, but sometimes we don't need to actually RUN the tests if we don't touch the python code in a particular PR. That's the other reason why I added the no-op, which is a workaround that somehow. There's no easy way to say "this check is required to pass ONLY IF IT TRIGGERS"
• Jobs using a build matrix have to be spelled out at their atomic level .asf.yml, AFAICT there's no way to put a check on the whole matrix

On the positive side:

• The workflow_dispatch trigger is SWEET, allowing people to parameterize a job and trigger it from the UI, or from the gh CLI