[bartlomieju]

Stacked on #8030; only the last two commits are new here.

This gives Rust APIs the trace spans that porting MemoryCache.read()
to Rust needs, so the Rust port records the same spans and tags as
the C++ implementation.

API

let mut span = ctx.make_trace_span(c"memory_cache_read")?;
span.set_tag(c"cache_hit", false);
let mut child = span.new_child(c"memory_cache_fallback");
let user_span = ctx.make_user_trace_span(c"memory_cache_read")?;

• IoContext::make_trace_span() and make_user_trace_span() call
  C++ makeTraceSpan() and makeUserTraceSpan(), so spans are
  children of the span current in the async context frame.
• SpanBuilder and TraceContext hold the C++ objects and end the
  spans when dropped. Like the C++ types, they stay on the
  IoContext's thread: neither is Send or Sync.
• SpanBuilder::set_tag(), SpanBuilder::new_child() and
  TraceContext::set_tag() mirror their C++ counterparts.

Strings

C++ expects span names and tag keys to be string literals, which it
does not copy. The Rust API takes them as &'static CStr (c"..."
literals), which cross the bridge with their NUL, so C++ wraps them
in a kj::ConstString with a null disposer, as it does _kjc
literals. A tag value can be a bool, an integer, a float, a literal
(not copied either), or a borrowed string, which is copied only if
the span is observed.

Async tracing

As in C++, a user trace span started just before await_io() is an
operation that the wait is reported under, instead of a bridge of its
own. This works because await_io() shares awaitIo()'s
implementation (#8030).

Tests

io-context-test.c++ records spans through a test SpanObserver:

• spans and children are recorded under the request's span, with
  tags of each type, and a tag set twice keeps its last value
• a span ends when its SpanBuilder is dropped
• spans and tags do nothing when the request is not traced
• await_io() reports its wait under the operation of a user trace
  span started before it

C++ MemoryCache: fallback_success overwrite

A separate commit fixes a span tag bug in the C++ MemoryCache.read(), which the Rust port has to reproduce tag for tag. The memory_cache_fallback span was tagged fallback_success=true before the fallback's result was validated; when validation then threw (a NaN expiration, or a value that cannot be serialized), the catch handler overwrote the tag with false. The final tags were right, but trace.c++ treats overwriting a tag as a programming error and logs it at ERROR in predictable mode. The tag is now set once the result is accepted. A new test in memory-cache-test.c++ records the spans of two rejected results and checks their tags; without the fix it fails on the overwrite's log.

[github-actions]

The generated output of @cloudflare/workers-types has been changed by this PR. If this is intentional, run just generate-types to update the snapshot. Alternatively, you can download the full generated types:

Full Type Diff