feat(spanv2): Double write to legacy attributes for backwards compatibility

[Ahmed-Labs]

Double writes SpanV2 attributes to legacy attributes to achieve backwards compatibility. With both conventions present in a span, V2 spans will continue to be compatible with our products while we simultaneously start accumulating spans that conform to sentry conventions.

DB and HTTP spans both fall back to legacy attributes, this is done so that when the transactions span pipeline gets unified into the span first pipeline, they continue to be normalized.

See DACI for more information: https://www.notion.so/sentry/DACI-Backwards-compatibility-for-span-first-attribute-conventions-2c48b10e4b5d802dbfc3d90610b2537b?source=copy_link

Note: bumps sentry conventions

[jjbayer]

@loewenheim could this be covered by generic double-write rules in sentry conventions instead?

[Dav1dde]

What @jjbayer mentioned, would be interested if the deprecation flow we added to conventions doesn't already cover this case, as it seems quite straight forward 1:1 mapping. If it does not, what changes do we need to make to get this covered?

[Dav1dde]

We want to have all attributes used defined in relay-conventions/src/consts.rs and added to conventions, unless there is a good reason not to add it to conventions.

I think even adding (still in use) legacy attributes to the conventions has values.

[Ahmed-Labs]

I just thought that since legacy attributes like http.request_method don't align with OTel and we're going in a direction where the SDKs won't be sending it at all, it would be counter productive to include it. I do also see value in adding it to conventions tho because that attribute will always be present in some spans (even with span first, there will be people with unupgraded SDKs I guess).

[Ahmed-Labs]

What @jjbayer mentioned, would be interested if the deprecation flow we added to conventions doesn't already cover this case, as it seems quite straight forward 1:1 mapping. If it does not, what changes do we need to make to get this covered?

The problem is that the mapping isn't 1:1, for example sentry.action maps to db.operation.name,http.request.method, and more. I don't think there's a way to mark the legacy attribute as deprecated and have it be replaced by multiple attributes. Some of these attributes are also not being deprecated, just used for different reasons (like sentry.description), so marking them as deprecated could be problematic (whether in eap queries or relay attribute name normalization).

So to make this work we would probably have to add something like a legacy/fallback field to conventions where you can specify fields to write back to. That way, we don't have to falsely mark deprecation, and we would know which attribute http.request.method maps back to (even if other attributes fall back to the same attribute).

[Ahmed-Labs]

Following up on this, I've added the attributes to sentry conventions (PR) and updated my changes accordingly.

Note: I wasn't able to add http.request_method because upon adding it, the conventions code gen created conflicting variable names with the existing http.request.method attribute (in the generated libraries) because it doesn't differentiate between periods and underscores in all cases. So it seems like the sentry conventions code gen needs to be updated, and I've created a ticket for it.