scrypted: noDelay:true on keep-alive sockets — kills 200ms Nagle deadlock

After enabling keep-alive in bccf0fa, fw_recv p95 spiked from ~25ms
to ~230ms on a significant fraction of frames and net_up p95 went
from <15ms to 200+ms simultaneously. Worst frames hit 467ms wall.

Root cause: Node http.Agent's outgoing sockets default to noDelay
false (Nagle ON). When a ~128KB JPEG body doesn't end on an exact
MTU boundary, the sender holds the final partial packet for up to
200ms waiting for either more data or a peer ACK. Firmware-side
TCP_NODELAY only controls what the firmware *sends* (its ACKs and
response packets); it has no effect on what arrives at the firmware
from a Nagling sender.

Setting noDelay: true on the http.Agent makes new sockets in the pool
opt out of Nagle on creation. Plus a belt-and-suspenders setNoDelay
on the request's socket event in case the Agent-level option isn't
honored on this Node version.

The 230ms signature is the classic Nagle + delayed-ACK deadlock:
- Sender: "I have a partial packet; I'll wait for more data or an
  ACK before sending."
- Receiver: "I'll delay this ACK up to 200ms in case I can piggyback
  it on a response."
- Result: 200ms stall on every send that doesn't fill an MTU.

0 files changed, 0 insertions, 0 deletions