connmgr: add ability to send large response headers

[jkarneges]

Similar to #48368, this adds support for sending large headers in the other direction.

Currently, response headers are first written to the task's write buffer, and then the content of that buffer is written to the client socket. With this change, the response headers are written directly to the client socket, allowing headers of arbitrary size to be sent.

This change also obsoletes the "overflow" feature for response body data, whereby any initial body data (up to the buffer size) that can't fit alongside the header data within the task's write buffer spills over into a separate heap-allocated buffer. For example, if the write buffer size is 16k and the header data is 4k, then up to 16k of initial body data will be allowed but only 12k will be able to fit alongside the header data in the write buffer, in which case a temporary 4k heap allocation will be used to hold the remaining initial body. Now that we no longer write the header data to the buffer, the allowed initial body data always fits in it, and thus the prepare method always returns an overflowed byte count of zero.

As before, we have to move some variables around in the server connection tasks to ensure they live for the duration of header sending. Part of this involves keeping some variables higher up in the call stack where they are not yet used and then passing down mutable references to them. For example, the IPC message carrying response data is received deep in the call stack and then moved via reference into a variable that lives higher in the call stack, allowing data to be returned that borrows from the message. This works because the message has been moved out of the function and can survive the function returning. These kinds of params that the callee fills in but are not directly used by the caller afterwards are often labeled as "scratch" params, to differentiate them from "out" params.

Also, as before, moving variables around causes the task sizes to increase, so the size thresholds are updated. I'll take a look at optimizing the sizes afterwards, if at all possible.

Relatedly, keeping an IPC message around for the duration of sending its contents to the client requires excluding it from our special tracking mechanism. The track module is used to enforce lifetimes of IPC messages, such that only one tracked message exists at a time per task and that the message is processed timely. This PR adds an into_inner method to Track, making it possible for a task to optionally exclude a message from tracking. We didn't need to do this earlier for request headers since the IPC message acting as the source data for outbound requests already begins in an untracked state.