feat: add lambda-runtime-invocation-id header

[darklight3it]

Summary

Add Lambda-Runtime-Invocation-Id header support for cross-wiring protection.

The RIC now echoes the invocation ID received from RAPID on /next back on /response and /error, enabling RAPID to detect and reject stale responses from timed-out invocations.

Problem

On Lambda Managed Instances (LMI) and On-Demand (OD), when an invoke times out, the runtime process continues running in the background. If a new invoke arrives with the same requestId, RAPID accepts it. The still-running old invocation eventually posts its response, and RAPID matches it to the new invoke — delivering the wrong response (cross-wiring).

Solution

RAPID sends a unique per-invoke nonce via Lambda-Runtime-Invocation-Id header on /next. The runtime echoes it back on /response and /error. RAPID validates the match before accepting the response.

Backward Compatibility

Fully backward compatible in both directions:

• If RAPID doesn't send the header → RIC doesn't see it → doesn't echo → no behavior change
• If RIC doesn't echo it (old version) → RAPID skips validation → no behavior change

Rate-limited malformed-header logging

Added an internal generic RateLimiter for runtime different uses. In this case the request was to rate limit warning caused by malformed Lambda-Runtime-Invocation-Id headers.

The limiter:

• Uses a monotonic Instant and configurable Duration.
• Is protected by a standard mutex because the check-and-update operation must be atomic across concurrent Tokio tasks.
• Is process-local, so a static limiter is shared across warm invocations in the same Lambda execution environment.
• Resets its timestamp and clears mutex poisoning if the mutex is poisoned, since the limiter state is disposable and must not crash the runtime.
• Keeps rate-limiting independent from tracing, allowing a future tracing-subscriber integration without coupling the runtime behavior to a specific subscriber.

Malformed invocation-ID headers are ignored rather than converted with from_utf8_lossy, because the value may be echoed back as an HTTP header and must remain a valid ASCII header value. A rate-limited warning is emitted with the configured interval included as structured log metadata.

Testing

• added unit test
• added a new dockerized test working with the new RIE.

[jlizen]

Core approach is good, but some small tweaks.

Also: currently we log Lambda function timeout! for any 410, but we now will have a 410 if a stale response is rejected. We should tweak the message.

[jlizen]

This will error out and crash the runtime if a malformed invocation id header is sent.

We originally decode with String::from_utf8_lossy(), but that replaces non-utf8 bytes with U+FFFD which is anyway not ascii. So then this parse will fail.

I did a quick check and didn't find any other round trips, this new code is the only place impacted.

I know we control the sender but we should be defensive against malformed inputs anyway. I would suggest a rate-limited log warning if we have bad bytes.

[darklight3it]

Done! I also added a general rate_limiter class. I made it very generic so it can be reused in the runtime.

We can probably open an issue to see if we can use it in other places. And evaluate integration with logging mechanism.

Another thing I would think about is to offer this capabilities to our reexported logging to offer the possibility for the customer to use our own logging and a very convenient rate limiter.