Update span enrichment to align with existing APM data logic

[isaacaflores2]

Overview

Traditional APM event ingestion utilized enrichment from the apm-data lib. With the introduction of the receiver/elasticapmintake component (which is using apm-data internally) it is possible for a collector to have a pipeline such as: receiver/elasticapmintake -> processor/elasticapm.

Changes

• Add missing enrichment for service.instance.id aka service.node.name. The logic follows the existing apm-data logic here
• Update the existing span enrichment flow to not override existing values for certain fields. The is needed for events that have already been processed by the apm-data library. The changes here aim to preserve the existing field values and existing apm-data enrichment behavior.
• Add more resource attributes to the elasticattr package. The goal here is to utilize these constants in other components such as the processor/elasticapm

[isaacaflores2]

@gregkalapos or @lahsivjar I would appreciate an extra pair of eyes on this PR whenever you get a chance

[gregkalapos]

Looks ok to me.

I think the logic to not overwrite an existing value could be applied to all fields.

From what I remember, the enrichment lib here was written assuming we enrich OTLP data, so the assumption was that none of the Elastic specific fields is set. But this is very different with the elasticapmintake receiver.

I think it's fine to merge it this way, but overall a general logic to keep existing values could be added everywhere.

[isaacaflores2]

Thanks @gregkalapos. I will follow up with generic logic to not override existing values everywhere