Make `pod_spec_patch` more accessible

[flaviuvadan]

Is your feature request related to a problem? Please describe. It is incredibly cumbersome to write out a pod spec patch specification. One can do it either as a plain string ('{"containers":[{"name":"main", "resources":{"limits":{"cpu": "{{workflow.parameters.cpu-limit}}" }}}]}') or via json.dumps({'containers': [{'name': 'main', ...}]}). json.dumps is nicer because users don't have to spend time fiddling with quotes but the whole concept is challenging to grasp.

Describe the solution you'd like A way for Hera to set up these dynamic pod spec patches for the user. A way for script to know when to patch and when to not patch perhaps.

Describe alternatives you've considered Not doing it at all and going with status quo

[elliotgunton]

Considering the actual spec has

    pod_spec_patch: Optional[str] = Field(
        default=None,
        alias="podSpecPatch",
        description=(
            "PodSpecPatch holds strategic merge patch to apply against the pod spec. Allows parameterization of"
            " container fields which are not strings (e.g. resource limits)."
        ),
    )

I would suggest a Hera pydantic class with a build function, and add a union type with it for Workflows https://github.com/argoproj-labs/hera/blob/b13811ab8548bd4a169c330c8dd777ce0794e90e/src/hera/workflows/workflow.py#L225

and templates https://github.com/argoproj-labs/hera/blob/b13811ab8548bd4a169c330c8dd777ce0794e90e/src/hera/workflows/_mixins.py#L438

💯

[flaviuvadan]

@elliotgunton I assume you're suggesting a style of parsing a pod spec patch rather than setting the pod spec patch on the workflow right? pod spec patching is set on a template level. If that's the case I think I agree - Hera needs a way to map some lighter pod spec patch specification to the actual pod spec patch string