Set delete propagation policy to background when removing jobs and its dependents

[soltysh]

What type of PR is this?
/kind bug

Which issue(s) this PR fixes:
Fixes #71772

Special notes for your reviewer:
/assign @liggitt @juanvallejo

Does this PR introduce a user-facing change?:

Fixes pod deletion when cleaning old cronjobs

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: soltysh

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• pkg/controller/cronjob/OWNERS [soltysh]
• test/e2e/apps/OWNERS [soltysh]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[soltysh]

/sig apps
/priority critical-urgent

/assign @aleksandra-malinowska @tpepper
for 1.13 approval

[juanvallejo]

/lgtm

[liggitt]

/lgtm

this fixes a regression in the cronjob controller in 1.13

[aleksandra-malinowska]

Is there any reason this can't be an automated cherry-pick of #71801?

[soltysh]

Is there any reason this can't be an automated cherry-pick of #71801?

When I was fixing those I've opened manual PRs for both by cherry-picking PRs. Automatic works only after you have a PR open. Is that a problem?

[soltysh]

Iow. I did git cherry-pick locally.

[aleksandra-malinowska]

@soltysh I'm familiar with making both automated and manual cherry-picks, thanks. I was under the impression that there was a policy for using automated if possible (i.e. unless the PR doesn't go to master at all, or there are conflicts, etc.), but I can't find the source, so maybe it's just that (some) past branch managers required of (some) contributors.

@tpepper LMK if you're OK with skipping the automated cherry-pick process in this case.

[tpepper]

When PR'ing directly manually against the branch, there is increased risk that we merge a patch that is different than what ultimately merged to master. After reviewing this one, I'm OK with going ahead with merging as it is in sync.

While the workflow may seem equivalent, or even slightly annoying versus straight manual git for those familiar with that, a very beneficial aspect of the cherry pick automation is that we as patch maintainers automatically know that the patch is the same as what went into master. This is important for us to know as a cohesive project that we don't have slight accidental variations across branches.

I will work to update the documentation to be more clear that manual cherry picks should be exceptional to deal with some emergent situation that requires the action ahead of PR'ing to master.

[liggitt]

/retest