feat(wasi-observe): WASI Observe factor implementation

[calebschoepp]

• Adds a new WASI Observe factor.
• Adds a suite of integration tests for the factor.
• Makes all other factors take an optional dependency on the ObserveFactor to handle proper span nesting of other factors.

[calebschoepp]

This was necessary to make fake-opentelemetry-collector happy which relies on an up to date version of tokio.

[calebschoepp]

Some of these conversions end up being fallible b/c we're parsing things that must conform to a format. Right now I handle this by just quelling the error and silently omitting the invalid data. This doesn't feel like a great user experience (even if it is documented in the WIT interface).

An alternative would be to make this try_from and then expose the error out through the WIT interface. This would make change:

• start: func(name: string, options: option<start-options>) -> span; to start: func(name: string, options: option<start-options>) -> result<span>;
• add-link: func(link: link); to add-link: func(link: link) -> result<()>;

I don't love the idea of exposing errors out of these functions just for the incorrect parsing of a span context. I'm not sure what the right choice is here.

[calebschoepp]

I couldn't figure out how to put this module in another file, but still import things from the testcases module.

[calebschoepp]

I would suggest that we land WASI Observe as a release candidate wasi:[email protected]. I think it is the right choice to put it in the WASI namespace b/c WASI Observe is a phase 1 proposal.

If we're feeling conservative we could add this to a new http-trigger-experimental world where we make less support guarantees.

package fermyon:spin@2.0.0;

/// The full world of a guest targeting an http-trigger
world http-trigger {
  include platform;
  export wasi:http/incoming-handler@0.2.0;
}

/// Like `http-trigger`, but using WASI 0.2.0-rc-2023-10-18
world http-trigger-rc20231018 {
  include platform-rc20231018;
  export wasi:http/incoming-handler@0.2.0-rc-2023-10-18;
}

/// Like `http-trigger`, but experimental and with no support guarantees
world http-trigger-experimental {
  include platform-experimental;
  export wasi:http/incoming-handler@0.2.0;
}

/// The imports needed for a guest to run on a Spin host
world platform {
  include wasi:cli/imports@0.2.0;
  import wasi:http/outgoing-handler@0.2.0;
  import llm;
  import redis;
  import mqtt;
  import postgres;
  import mysql;
  import sqlite;
  import key-value;
  import variables;
}

/// Like `platform`, but using WASI 0.2.0-rc-2023-10-18
world platform-rc20231018 {
  include wasi:cli/reactor@0.2.0-rc-2023-10-18;
  import wasi:http/outgoing-handler@0.2.0-rc-2023-10-18;
  import llm;
  import redis;
  import mqtt;
  import postgres;
  import mysql;
  import sqlite;
  import key-value;
  import variables;
}

/// Like `platform`, but experimental and with no support guarantees
world platform-experimental {
  include platform;
  include wasi:observe/imports@0.2.2-rc2024-09-17;
}

[calebschoepp]

@dicej does adding a new interface to a wold constitute a breaking change?

[calebschoepp]

TODO item for Caleb: It seems that this is not working with the Rust spin_sdk``v3.0.1.