Fix fluentbit service selector not using pod labels when defined

[solidDoWant]

What this PR does / why we need it:

When spec.labels is defined, it is used to label created daemonset pods instead of metadata.labels. This causes the service, which always uses metadata.labels, to not select pods in some cases.

Unfortunately, because spec.labels is defined as map[string]string instead of a *map[string]string, it's not possible to tell the difference between a null spec.labels value (labels: ~, labels: null, or labels not set) and an empty spec.labels value (labels: {}). I think it's highly unlikely that anybody is doing this today, but if so, this could possibly be a breaking change.

Which issue(s) this PR fixes:

N/A

Does this PR introduced a user-facing change?

Fixed fluent bit service not always selecting pods when pod labels are set via `spec.labels`.

Additional documentation, usage docs, etc.:

N/A

[marcofranssen]

Any chance we can test this? e.g. unit or e2e test to prevent it breaking again in future?

[Copilot]

Pull Request Overview

This PR fixes an issue where the Fluent Bit service selector was not using pod labels defined in fb.Spec.Labels. The changes ensure that if fb.Spec.Labels is provided, it is used as the service selector instead of the default fb.Labels.

• Introduced a new variable, podLabelSelector, to determine which label set to use.
• Updated the service specification to utilize podLabelSelector for pod selection.

[Copilot]

The current logic duplicates label assignment by using a separate variable podLabelSelector. Consider refactoring the label assignment to directly use fb.Spec.Labels when available, to improve clarity and maintainability.

Suggested change

	podLabelSelector := fb.Labels
	if len(fb.Spec.Labels) > 0 {
	podLabelSelector = fb.Spec.Labels
	podLabelSelector := fb.Spec.Labels
	if len(podLabelSelector) == 0 {
	podLabelSelector = fb.Labels