Expand KPO template_fields, fix Spark k8s operator tests

[insomnes]

Adding name and hostname to KubernetesPodOperator template_fields

• Move name validation and normalization inside execute method
• Expand KubernetesPodOperator tests
• Refactor create application SparkKubernetesOperator due to bug in tests
• Fix kubernetes_tests/test_kubernetes_pod_operator.py too long name testing flow and add this case to unit tests

closes: #43480
Based on previously staled PR

---

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

[insomnes]

I was interested in this feature so I've bring back staled PR with some extra tests, maybe we can succeed with it this time

[insomnes]

I think, I've found the bug in spark k8s operator test code. Will check and try to fix for affected test and bring the bug issue to fix any other occurrences

[insomnes]

The mentioned bug in the spark k8s operator test is related to mocking and new changes.

Previously, tests were failed because the new KPO execute() validates the name set for a pod on an operator by calling _set_name (because of templating changes, we need to have context applied to templates before name validation).
Thus the tests in k8s spark operator with mock_create_job_name could not succeed. MagickMock is not a str instance, so validation failed.

This led me to understand that calls to assert op.name.startswith("...") are broken in these tests, otherwise, they would fail too (this is checked after operator execution). My investigation showed that changing prefix to anything like name.startswith("ABRA-CADABRA") didn't lead to test fails. Functions with applied unittest.patch actually return MagicMock object, so the op.name was a MagicMock instance in these tests.

Any method call on instance of MagickMock doesn't fail by design and returns another MagicMock object. They lead to positive assertions. That's why I have refactored affected spark k8s operator tests. I've extracted create_application tests to a separate class where create_job_name is not patched.

I believe that all affected tests are fixed now. So there is no need for a new issue.

[shahar1]

LGTM!