Add pdbs for triggerer and workers

[mrrsm]

Description

This will add the ability to set pod disruption budget resources for either the triggerer and/or worker pods. These are disabled by default as to not cause a breaking change in the helm chart.

Why

We are running multiple instances of triggerer pods as well as worker pods. When we have a cluster event that may take out a node having the PDB allows us to not have multiple instances of the same pods go down at the same time.

---

[boring-cyborg]

Congratulations on your first Pull Request and welcome to the Apache Airflow community! If you have any issues or are unsure about any anything please check our Contributors' Guide (https://github.com/apache/airflow/blob/main/contributing-docs/README.rst)
Here are some useful points:

• Pay attention to the quality of your code (ruff, mypy and type annotations). Our prek-hooks will help you with that.
• In case of a new feature add useful documentation (in docstrings or in docs/ directory). Adding a new operator? Check this short guide Consider adding an example DAG that shows how users should use it.
• Consider using Breeze environment for testing locally, it's a heavy docker but it ships with a working Airflow and a lot of integrations.
• Be patient and persistent. It might take some time to get a review or get the final approval from Committers.
• Please follow ASF Code of Conduct for all communication including (but not limited to) comments on Pull Requests, Mailing list and Slack.
• Be sure to read the Airflow Coding style.
• Always keep your Pull Requests rebased, otherwise your build might fail due to changes not related to your commits.
  Apache Airflow is a community-driven project and together we are making it better 🚀.
  In case of doubts contact the developers at:
  Mailing List: dev@airflow.apache.org
  Slack: https://s.apache.org/airflow-slack

[Miretpl]

Hi @mrrsm, could you add a test cases?

[jscheffl]

Thanks for the contribution. I think this makes sense and per default it is disabled which is fine. I am not sure when enabled that the defautls are also fine but depends very much on the deployment and scope.

I approve and keep it open for 1-2 days for another pair of eyes, else can be merged in my view.

[Miretpl]

In general looks good, small nits.

Also, one question to @jscheffl or/and @jedcunningham. PR #52357 introduced the workers.kubernetes and workers.celery sections. Changes in this PR will only affect the workers created by CeleryExecutor. So maybe this and similar new values should be placed under proper sections (maybe it is worth to discuss on devlist)? What do you think?

[mrrsm]

@Miretpl Thank you for the review/changes.

In an effort to not add a different way to do PDBs should I also update the PDB's and tests that already exist for other components (scheduler, api-server, etc) to match the style in this PR and also update the tests to remove the unneeded kubernetes version test?

[Miretpl]

@mrrsm, consistency across the entire Helm Chart would be something nice to have, but I believe that combining everything in one PR can become a little harder to merge (based on my experience). Personally, I would probably do 2 additional PRs after this one:

1. for making the PDB consistent between components
2. removal of other unneeded tests, which are testing stuff for currently unsupported Kubernetes versions

[jscheffl]

@Miretpl as of the updated, previously you requested changes - OK to merge? (In my view it is good)

[Miretpl]

@jscheffl in general looks good to me. I have just placed one comment that should resolve the tests. If they are green, we can merge it

[boring-cyborg]

Awesome work, congrats on your first merged pull request! You are invited to check our Issue Tracker for additional contributions.