[collector] Respect pipeline order when enabling kubernetesAttributes

[JDemler]

When enabling kubernetesAttributes an k8sAttributes processor is automatically prepended to all available pipelines.
There are situations where one relies on another processor to provide or prepare data for k8sAttributes to work correctly.

This change makes sure that when a k8sAttributes -processor was added manually to a pipeline, the pipeline itself is not touched to preserve its order.
As communicated in UPGRADING.md this might break existing installations when they implicitly relied on k8sAttributes being run first but explicitly configuring it otherwise in the values.yaml.

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: JDemler / name: Jakob Demler (5942a0a, dafaa5c, 1f84a95, ce169c2, 8e9966d)

[TylerHelmuth]

Thanks for this contribution. The breaking change is so obscure that I'm tempted to not even call it out, @dmitryax @povilasv what do you think?

[povilasv]

This is interesting, I was kind of under impression that this is how presets should work, i.e. when enabled they are prepended to all pipelines without any user control. And if you need control do things without the preset.

But this approach is interesting, if we merge this, should we use the same approach for other presets?

[TylerHelmuth]

@povilasv since most of the presets are receivers prepending to the front doesn't affect anything, but for processors I can see the argument for wanting to get the value of the preset while still placing it specifically in the pipeline. I think this is a good compromise between the preset's value and our goal to not make them configurable since it is configuring the .Values.config section instead of the preset.

[povilasv]

Thanks for your thoughts. I agree 👍

[TylerHelmuth]

@JDemler I merged in an older PR, please rebase.

[JDemler]

Thanks! That was a painless process :)