fix: resource deletion and adoption for 3 controllers

[ksdpmx]

What this PR does / why we need it:

resources like sa, svc and sts haven't been generated before calling Delete() which leads to the remaining finalizer for collector.
resource deletion and adoption cleanup and fix for 3 controllers

Which issue(s) this PR fixes:

Fixes #

Does this PR introduced a user-facing change?

None

Additional documentation, usage docs, etc.:

[ksdpmx]

"2023-06-06T03:10:30Z ERROR Reconciler error {"controller": "collector", "controllerGroup": "fluentbit.fluent.io", "controllerKind": "Collector", "Collector": {"name":"fluent-bit-collector","namespace":"fluent"}, "namespace": "fluent", "name": "fluent-bit-collector", "reconcileID": "b0128934-0ce5-4a21-9105-aa7df920cddd", "error": "error when handling finalizer: resource name may not be empty"}"

related comment for reference: #776 (comment)

steps to reproduce:
1.

cat <<EOF > co.yaml
apiVersion: fluentbit.fluent.io/v1alpha2
kind: Collector
metadata:
  labels:
    app.kubernetes.io/name: fluent-bit
  name: fluent-bit-collector
  namespace: fluent
spec:
  annotations:
    fluentbit.io/exclude: "true"
  fluentBitConfigName: fluent-bit-config
  image: kubesphere/fluent-bit:v2.1.4
EOF

2. kubectl create -f ./co.yaml
3. kubectl delete -f ./co.yaml, this step will get stuck
4. check logs from operator

[wanjunlei]

I think it can call the delete directly like this

	sa := corev1.ServiceAccount{
		ObjectMeta: metav1.ObjectMeta{
			Name: co.Name,
			Namespace: co.Namespace,
		},
	}
	if err := r.Delete(ctx, &sa); err != nil && !errors.IsNotFound(err) {
		return err
	}

No need to call get.

[ksdpmx]

it seems like other controllers (fluentbit, fluentd) have to update like this as well.
btw, does it make sense to check the owner reference before deletion? what if there's another resource which is not managed by this operator (i.e. fluentbit collector) with the same name?

[ksdpmx]

@wanjunlei PTAL. thank you. cc @benjaminhuo

delete for finalizer & dangling resources and mutate for resource reconciliation & adoption have been updated for all 3 controllers.

what if there's another resource which is not managed by this operator (i.e. fluentbit collector) with the same name?

the lifecycle of the existing resources without owner reference but with the same name will be managed by this operator, like creation, updating, deletion.
the deletion logic for clusterrole and clusterrolebinding is not included in this pr yet.

[benjaminhuo]

@wanjunlei are you ok with @ksdpmx‘s new change?

[benjaminhuo]

@ksdpmx Thank you for this big refactoring