pool: file: object: clean up health checkers for both types of deletion (backport #9094)

[mergify]

This is an automatic backport of pull request #9094 done by Mergify.
Cherry-pick of 03ba7de has failed:

On branch mergify/bp/release-1.7/pr-9094
Your branch is up to date with 'origin/release-1.7'.

You are currently cherry-picking commit 03ba7dec6.
  (fix conflicts and run "git cherry-pick --continue")
  (use "git cherry-pick --skip" to skip this patch)
  (use "git cherry-pick --abort" to cancel the cherry-pick operation)

Unmerged paths:
  (use "git add <file>..." to mark resolution)
	both modified:   pkg/operator/ceph/file/controller.go
	both modified:   pkg/operator/ceph/object/controller.go
	both modified:   pkg/operator/ceph/pool/controller.go

no changes added to commit (use "git add" and/or "git commit -a")

To fix up this pull request, you can check it out locally. See documentation: https://docs.github.com/en/github/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/checking-out-pull-requests-locally

---

Mergify commands and options

More conditions and actions can be found in the documentation.

You can also trigger Mergify actions by commenting on this pull request:

• @Mergifyio refresh will re-evaluate the rules
• @Mergifyio rebase will rebase this PR on its base branch
• @Mergifyio update will merge the base branch into this PR
• @Mergifyio backport <destination> will backport this PR on <destination> branch

Additionally, on Mergify dashboard you can:

• look at your merge queues
• generate the Mergify configuration with the config editor.

Finally, you can contact us on https://mergify.com

[leseb]

@BlaineEXE PTAL at the conflicts, thanks.

[BlaineEXE]

I've been looking at the conflicts, and I've given up on resolving them twice already. I can take another stab at it and probably make some better progress, but I have been wondering if the time spent massaging the conflicts is really worth it. After all, the workaround for the goroutine leaks is to restart the operator, which is pretty simple. I don't see a strong reason to spend several more hours on this given other things that need doing. I'm also open to someone giving me a good reason to light a fire under my butt to give this another go.

[travisn]

I've been looking at the conflicts, and I've given up on resolving them twice already. I can take another stab at it and probably make some better progress, but I have been wondering if the time spent massaging the conflicts is really worth it. After all, the workaround for the goroutine leaks is to restart the operator, which is pretty simple. I don't see a strong reason to spend several more hours on this given other things that need doing. I'm also open to someone giving me a good reason to light a fire under my butt to give this another go.

Since 1.8 is so close, how about we not worry about this? Or was there a specific request for this backport?

[BlaineEXE]

Since 1.8 is so close, how about we not worry about this? Or was there a specific request for this backport?

I think the request was that it would be nice, but I'm not sure we realized it would be this complex to backport.

[leseb]

It seems that the original PR was a cleanup/refactor so not something critical to backport, nice to have as @BlaineEXE mentioned. Also, 1.8 is relatively close so let's not worry too much for now.