Upgrade to `opentelemetry_sdk` 0.32.1 to address vulnerability

[dicej]

#3595 required updating spin-timer's Cargo.lock file, which bumped opentelemetry_sdk's version, which caused the "Review new dependencies for known vulnerabilities" CI check to fail due to GHSA-w9wp-h8wv-79jx.

That's technically a false positive since both the old and new versions of that dep are vulnerable, and the version bump was done in the top level Cargo.toml a month ago. In any case it needs to be addressed, but since it's unrelated to the PR, I'm going to disable the check temporarily with a comment to re-enable it once this issue has been addressed.

FWIW, I took a stab at addressing it myself, but it turned into a rabbit hole, so I had to punt.

[itowlson]

I started looking at this. It's not in a PR-able state and I dunno if I'll be able to get it to a PR-able state, but just so folks know rather than duplicating effort. I'm hoping Caleb will be able to offer insight and direction.

[ChihweiLHBird]

I took a look into this, and I think it's a bigger issue than I thought. Even if the upstream OTel Rust SDK will implement the MetricProducer in the future, it will still be very complex to support the wasi-otel with the OTel SDK.

The OpenTelemetry Metrics SDK is organized around reader-driven collection. A MetricReader defines collection timing and collection boundaries, and exporters receive metric data from the reader/export pipeline. The OpenTelemetry specification also defines MetricProducer as the bridge for external or pre-processed metric sources, but the producer is still expected to provide data when the reader collects.

By contrast, wasi:otel/metrics lets a guest submit already-aggregated metric data at guest-chosen times. From the host's point of view, this looks like an asynchronous stream of pre-aggregated external metric data arriving outside the host SDK's normal collection cycle.