build(deps)!: Upgrade to opentelemetry 0.32

[jens1o]

Upgrades the OTel dependency stack to opentelemetry 0.32 / tracing-opentelemetry 0.33 and bumps the crate to 8.0.0 per the established "OTel minor = breaking" policy.

There was a breaking change in tracing-opentelemetry, see https://github.com/tokio-rs/tracing-opentelemetry/releases/tag/v0.33.0 - I oriented myself after this example to see how they suggest it: https://github.com/tokio-rs/tracing-opentelemetry/blob/1d5422f1f37932fd65e434da618b305d4c94ee9c/examples/otel_context.rs

[jens1o]

I want to test this in my setup using a hot patch in our nonprod-setup, I'll report back whether it works - tests are passing on my local dev machine.

[jens1o]

I can confirm that this works on a nonprod deployment, I used

# Hotpatch: point at jens1o's fork until open-schnick/DatadogFormattingLayer#23
# is merged and a v8 release lands on crates.io.
datadog-formatting-layer = { git = "https://github.com/jens1o/DatadogFormattingLayer.git", rev = "098c2c0bc1dbe0a8b2ff33fbbc131fb92c016dbc" }
# Pinned to match the versions that `datadog-formatting-layer` (PR #23, v8) was
# compiled against. Bumping past these splits the OTel global state into
# two parallel copies and breaks trace ↔ log correlation (the dd layer
# can no longer find the `OtelData` extension the layer wrote in).
opentelemetry = "0.32"
opentelemetry_sdk = { version = "0.32", features = ["rt-tokio"] }
opentelemetry-datadog = { version = "0.20", features = [
    "reqwest-blocking-client",
] }
tracing-opentelemetry = "0.33"

[open-schnick]

So you did verify that logs, traces and log correlation still works? (it should as the tests are not failing, but maybe the other deps changed stuff)

[open-schnick]

the version will get bumped automatically by release-plz