chore: using domain-qualified finalizers

[trutx]

Tracking issue

Closes #6019

Why are the changes needed?

Switching to domain-qualified finalizers. Kubernetes introduced a warning in kubernetes/kubernetes#119508 so using old finalizers is harmless today, but updating them for the sake of clean Flyte admin logs and in advance of possible future enforcements of such finalizers.

What changes were proposed in this pull request?

• Switch to a global domain-qualified finalizer: from flyte-finalizer to flyte.lyft.com/finalizer
• Switch the k8s plugin finalizer from flyte/flytek8s to flyte.lyft.com/finalizer-k8s
• Switch the array plugin finalizer from flyte/array to flyte.lyft.com/finalizer-array
• Remove the finalizers.go and finalizers_test.go files and start leveraging the finalizer goodies in the upstream controllerutil package
• Keep the removal of the old finalizer for backwards compatibility. It will no longer be added. This part should be eventually removed
• Stop removing all finalizers and only remove Flyte's instead. This allows users to add their own finalizers

How was this patch tested?

Unit tests were modified to check for the presence/absence of the new finalizer. Some new tests were added and some existing tests were fixed so that clearFinalizer() func was actually run.

Setup process

Screenshots

Check all the applicable boxes

• I updated the documentation accordingly.
• All new and existing tests passed.
• All commits are signed-off.

Related PRs

Docs link

[codecov]

Codecov Report

Attention: Patch coverage is 53.65854% with 19 lines in your changes missing coverage. Please review.

Project coverage is 37.06%. Comparing base (d1a723e) to head (eb45eb2).
Report is 7 commits behind head on master.

Files with missing lines	Patch %	Lines
flyteplugins/go/tasks/plugins/array/k8s/subtask.go	0.00%	12 Missing and 1 partial ⚠️
...er/pkg/controller/nodes/task/k8s/plugin_manager.go	62.50%	4 Missing and 2 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #6023      +/-   ##
==========================================
+ Coverage   37.03%   37.06%   +0.03%     
==========================================
  Files        1313     1315       +2     
  Lines      131622   132098     +476     
==========================================
+ Hits        48742    48963     +221     
- Misses      78652    78881     +229     
- Partials     4228     4254      +26     

Flag	Coverage Δ
unittests-datacatalog	51.58% <ø> (ø)
unittests-flyteadmin	54.10% <100.00%> (+0.02%)	⬆️
unittests-flytecopilot	22.23% <ø> (ø)
unittests-flytectl	62.46% <ø> (ø)
unittests-flyteidl	7.25% <ø> (ø)
unittests-flyteplugins	53.68% <0.00%> (-0.01%)	⬇️
unittests-flytepropeller	42.67% <77.77%> (-0.44%)	⬇️
unittests-flytestdlib	57.57% <ø> (+2.40%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

---

🚨 Try these New Features:

• Flaky Tests Detection - Detect and resolve failed and flaky tests

[trutx]

This updateBackoffRetries parameter ends up being e.updateBackoffRetries in

	retryBackoff := wait.Backoff{
		Duration: time.Duration(e.updateBaseBackoffDuration) * time.Millisecond,
		Factor:   2.0,
		Jitter:   0.1,
		Steps:    e.updateBackoffRetries,
	}

If this is unset (which it was in tests), then Steps: 0 which means _ = wait.ExponentialBackoff(retryBackoff, func() (bool, error) { inside Finalize() times out almost immediately, which effectively means e.clearFinalizer() is never called and the finalizer is never removed. The default setting is 5 but I think it's too dangerous a) to allow users to tweak these backoff settings, or b) to use an exponential backoff at all.

Thoughts?