Add a hard request deadline config for embedded HTTP servers

[carsonfarmer]

This adds an opt-in request deadline mode for embedders of spin-trigger-http.

The new API is:

let reuse_config =
    InstanceReuseConfig::single_use_with_request_deadline(timeout);

That config keeps the existing HTTP request timeout behavior, and also applies a hard deadline to the underlying Spin Store before guest HTTP code runs. This matters for CPU-bound guest code: an outer async timeout can stop waiting for a response, but it does not necessarily interrupt a tight Wasm loop. A store deadline does.

For this first version, the deadline config intentionally uses single-use instances. That keeps the API small and avoids subtle deadline-reset behavior for reused workers. Embedders that need hard per-request limits get correctness first, while the default config and CLI-created config remain unchanged.

The deadline is wired through the legacy Spin HTTP executor, WASI HTTP executor, Wagi executor, and the WASIp3 handler-state path.

Related issue: #3609

Validation:

cargo check -p spin-trigger-http
cargo test -p spin-trigger-http request_deadline_config_is_single_use

[dicej]

Thanks, @carsonfarmer!

This looks reasonable to me, although I think we should eventually combine request_timeout and request_deadline into a single field, making use of Store::epoch_deadline_async_yield_and_update to allow it to work with or without instance reuse and across the various flavors of handler (Spin, WASIp2, WASIp3, and WAGI). It's confusing to have two separate fields with overlapping responsibilities.

I'm fine with using the approach for now and opening an issue for future improvements, though.

[dicej]

Calling this a "hard request deadline" is a bit misleading given that the precision depends on the value of EngineBuilder::epoch_tick_interval (default: 10ms), the fuzziness of std::thread::sleep, and how often the epoch comparison happens in the compiled guest code. Perhaps we should note that the guest may run a bit longer than the specified deadline, but not arbitrarily longer?

[carsonfarmer]

Totally, fair point! I'll add that as part of the comment here.

[carsonfarmer]

I updated the language to be more tempered.

[dicej]

Also, would you be up for adding a simple integration test which verifies that the deadline is enforced for e.g. a WASIp2 guest that infinitely loops?

[carsonfarmer]

Also, would you be up for adding a simple integration test which verifies that the deadline is enforced for e.g. a WASIp2 guest that infinitely loops?

Good call, yes, absolutely. Integration test added.

[carsonfarmer]

I'm fine with using the approach for now and opening an issue for future improvements, though.

I created a follow up issue for future improvements. My confidence in implementing that is low, but I am willing to work on it.