feat: Add delivered HTTP call contexts to subnet call context manager

[eichhorl]

Currently, all HTTP request contexts are stored in the same collection of the subnet call context manager. They are removed once consensus delivers a response to the canister.

In the future, there will be a second "asynchronous refund" phase as part of the context's life cycle: After consensus delivers the HTTP response and an initial refund, consensus may continue to deliver asynchronous refunds, that correspond to shares which didn't make it into the original response.

To do this, the context needs to persist even after a response was delivered.

This PR proposes to support this by introducing a second collection, which will hold such delivered contexts. Whenever a response is delivered, the corresponding context is moved into the new collection.

An alternative would have been to mark the context as "delivered", e.g. by setting a boolean flag. However, introducing a second collection has some natural advantages:

1. The size of the collection holding undelivered contexts is limited. Including delivered contexts in the same collection would therefore adversely affect throughput.
2. Some places will only want to look at undelivered contexts (I.e. response share aggregation & validation).
3. Some places will only want to look at delivered contexts (I.e. async refund creation & validation)
4. Some places will want to look at both collections (I.e share validation & purging), for which we can simply take the union of both collections.

Note that for compatibility reasons, the new collection is still unused.

[zeropath-ai]

✅ No security or compliance issues detected. Reviewed everything up to d9a98fe.

Security Overview

• 🔎 Scanned files: 4 changed file(s)
• 🔗 Scan Link: https://zeropath.com/app/repositories/f5e9d2bb-29a4-4b64-902a-391d65fd8b2d?scanId=f4626ca7-92a8-45bf-bbc4-ded67692d925&codeScanTypes=PrScan&tab=issues

Detected Code Changes

Change Type	Relevant files
Enhancement	► metadata.proto     Add delivered_canister_http_request_contexts field ► state.metadata.v1.rs     Add delivered_canister_http_request_contexts field ► subnet_call_context_manager.rs     Add delivered_canister_http_request_contexts field ► proto.rs     Implement conversion for delivered_canister_http_request_contexts

[schneiderstefan]

This PR LGTM, as it's just some protobuf to/froms, but I have some high-level questions on where this is going.

At what point do we remove items from this list? Is there a bound on how much it can grow and/or can a malicious replica force that these entries are kept for an unreasonable amount of time?

[eichhorl]

This PR LGTM, as it's just some protobuf to/froms, but I have some high-level questions on where this is going.

At what point do we remove items from this list? Is there a bound on how much it can grow and/or can a malicious replica force that these entries are kept for an unreasonable amount of time?

@schneiderstefan the asynchonous refund phase will last for one minute, after which the context will be removed entirely. Replicas that haven't submitted a refund share until then are assumed to be offline/behind and their entire allowance will be refunded.

Currently we target 100 HTTP requests per second, which would lead to 6000 contexts over one minute:

ic/rs/config/src/execution_environment.rs

Lines 201 to 204 in bfcd00b

	/// Maximum number of http outcall requests in-flight on a subnet.
	/// To support 100 req/s with a worst case request latency of 30s the queue size needs buffer 100 req/s * 30s = 3000 req.
	/// The worst case request latency used here should be equivalent to the request timeout in the adapter.
	pub const MAX_CANISTER_HTTP_REQUESTS_IN_FLIGHT: usize = 3000;