In https://gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/2130 we added the functionality to allow for pod termination and pod cleanup grace periods to be specified. We should deprecate `terminationGracePeriodSeconds` in favour of `cleanup_grace_period_seconds` and `pod_termination_grace_period_seconds`. In addition, adding these fields introduces a need to manually handle behavior changes as to preserve backwards compatibility: With the new changes, if we don't specify any termination period, we'll have the values `nil, 0, 0`. So for both, `GetCleanupGracePeriodSeconds` and `GetPodTerminationGracePeriodSeconds`, `TerminationGracePeriodSeconds` will be `nil` so the value of zero will be specified. For `PodTerminationGracePeriodSeconds` the behavior will stay the same, we will pass the value of zero, however for `CleanupGracePeriodSeconds` the behavior will be different. [As per the API docs](http://gitlab.com/gitlab-org/gitlab-runner/blob/45472cdf02591942c9a95d2ce38ef5ff3a38d842/vendor/k8s.io/apimachinery/pkg/apis/meta/v1/types.go#L491-491), the value zero means `delete immediately` while before, we used to set the value to be `nil` since we didn't use it, which would fall back to using the grace period specified for the Pod. I confirmed that this is the case on `main`, this is the value by default in the final deployed Pod `terminationGracePeriodSeconds: 0`. It seems to me that the best compromise we can have right now is: * Convert all grace periods to pointers * Have checks to ensure that the default value of `CleanupGracePeriodSeconds` is zero, when not configured * Allow `PodTerminationGracePeriodSeconds` to be `nil` so that its default behavior can be utilized, which falls back to the configured `CleanupGracePeriodSeconds` * In the deprecation issue, remove the old `TerminationGracePeriodSeconds` field and allow both `CleanupGracePeriodSeconds` and `PodTerminationGracePeriodSeconds` to be `nil` by default so that their default behaviors can be invoked.