fix blocking node sample test

[brettsam]

Hopefully this really fixes NodeProcessCount_RemainsSame_AfterMultipleTimeouts. Previous change added more diagnostics and that allowed me to see that this test had some really weird behavior that could really only be chalked up to thread starvation. Logs like this:

Timeout value of 00:00:03 exceeded by function 'Functions.HttpTrigger-Timeout' (Id: 'a01f3c0f-a3dd-4026-b9cc-19f6ae707f45'). Initiating cancellation.
Executed 'Functions.HttpTrigger-Timeout' (Failed, Id=a01f3c0f-a3dd-4026-b9cc-19f6ae707f45, Duration=60687ms)

... a 3 second timeout but the function took exactly 1 minute.

Analysis led me to discover that the node function itself was blocking the thread entirely for 30 seconds with a tight while loop (so 2 invocations on one worker -> 60 seconds). It's possible that on these small CI machines the fact that we had 3 node processes blocking their threads was causing all the issues we see with this test.

That, at least, is the newest theory. This is a good fix either way and hopefully it removes the issue entirely.

Pull request checklist

IMPORTANT: Currently, changes must be backported to the in-proc branch to be included in Core Tools and non-Flex deployments.

• Backporting to the in-proc branch is not required
  • Otherwise: Link to backporting PR
• My changes do not require documentation changes
  • Otherwise: Documentation issue linked to PR
• My changes should not be added to the release notes for the next release
  • Otherwise: I've added my notes to release_notes.md
• My changes do not need to be backported to a previous version
  • Otherwise: Backport tracked by issue/PR #issue_or_pr
• My changes do not require diagnostic events changes
  • Otherwise: I have added/updated all related diagnostic events and their documentation (Documentation issue linked to PR)
• I have added all required tests (Unit tests, E2E tests)

[Copilot]

Pull request overview

This PR updates the Node.js HttpTrigger-Timeout sample function to avoid CPU-bound busy-waiting that can starve the Node event loop and make the NodeProcessCount_RemainsSame_AfterMultipleTimeouts end-to-end test behave unpredictably on constrained CI machines.

Changes:

• Replaced the tight while loop (busy wait) with a setTimeout-based delay to avoid blocking the Node event loop.
• Ensured the delayed completion path exits early (return) so the function doesn’t fall through to the synchronous context.done call.