feat: add async keyword to import functions

[asteurer]

This updates the dependencies of wasi:otel to their latest version and adds the async keyword to the relevant functions for the metrics, logs, and tracing interfaces. This will allow a guest to call e.g. metrics.export without having it block other concurrent tasks.

The only function I didn't use the async keyword with is the tracing.current-span-context, as the guest would be requesting the span context in that instance, and we would want to avoid a scenario in which the function call yields and the underlying context changes.

Additionally, I opted not to wrap any of the function args in a future keyword because the various OpenTelemetry SDKs will have already done the work of collecting/batching before reaching the point of calling these functions, so a future would be unnecessary.

Some additional notes:

• I've updated the package version to wasi:otel@0.3.0-rc.1-draft with the assumption that once this is merged we will start implementing in opentelemetry-wasi and working out any issues with the interface.
• I've removed the wkg.lock file because none of the other WASI proposals have one, and it felt like clutter.

[calebschoepp]

This seems plausibly useful to be async but I'd want to better understand what consuming this as async in opentelemetry-wasi would look like before we merge this.

[calebschoepp]

This seems plausibly useful to be async but I'd want to better understand what consuming this as async in opentelemetry-wasi would look like before we merge this.

[asteurer]

Hi y'all! I spent some time messing around with an implementation of the asyncified logs and metrics interfaces, and I'm no longer confident that it's going to be a good idea.

The portions of the Rust and Go OpenTelemetry SDKs that use concurrency features seem to assume that a metrics collector/log batcher is going to be running in the background and periodically exporting data on some interval. My understanding of how components are run (from a Wasmtime perspective) is that they aren't actively running as a background process, but only execute when invoked. We might be able to get this to work if we wanted to flip the model to have a host implementation pull data from components periodically; however, I think that the existing model of having components push data to the host is preferable.

Unless I'm missing something or there are other opinions, my vote is that we present the interface as-is to the wasi subgroup for phase 3.

@ricochet @calebschoepp

[calebschoepp]

I'd be curios on your perspective here @ricochet. I still don't have a super well formed understanding of how P3 would interact with wasi-otel