Fix issue with resourcedetection processor failing with no detectors …

[dsessler7]

…set.

Minor refactoring of some collector code.

Checklist:

• Have you added an explanation of what your changes do and why you'd like them to be included?
• Have you updated or added documentation for the change, as applicable?
• Have you tested your changes on all related environments with successful results, as applicable?
  • Have you added automated tests?

Type of Changes:

• New feature
• Bug fix
• Documentation
• Testing enhancement
• Other

What is the current behavior (link to any open issues here)?

We want to move to the newest version of the opentelemetry-collector-contrib, however, there was a change with the resourcedetection processor where having zero detectors set results in zero "successes" which results in a failure, killing the collector:
open-telemetry/opentelemetry-collector-contrib@50cd2e8

We therefore need to change our code so that we only add the resourcedetection processor if we have detectors set.

What is the new behavior (if this is a feature change)?

• Breaking change (fix or feature that would cause existing functionality to change)

We only add the resourcedetection processor to collector pipelines if there are detectors set in the postgrescluster/pgadmin manifests. Allows us to move to otel v0.144.0.

Other Information:

[tjmoore4]

❓ Did something change so that these checks are no longer necessary?

[dsessler7]

So, we checked them to ensure that accessing inCluster.Spec.Instrumentation.Logs wouldn't result in a nil pointer error, but the inCluster.Spec.Instrumentation != nil check happens in the OpenTelemetryLogsEnabled function call below anyways, so we can get rid of them and move the spec assignment inside the if block... That being said, OpenTelemetryLogsEnabled doesn't check that inCluster != nil, so we actually theoretically could have had nil pointer exceptions even before my change, although I don't really know if this is possible since I can't think of a reason why we'd be passing around a nil pointer to a v1beta1.PostgresCluster... Either way, probably a good idea to stick a check in there.

[tjmoore4]

❓ Same question as above.

[tjmoore4]

❓ Same here.