… trigger when running in debug mode.

A classic case of deadlock!

Internally, the Functions Emulator maintains a work queue which processes unit of work called "tasks" with configured parallelism.

When Functions Emulator runs in debug mode, the work queue runs in `SEQUENTIAL` mode where tasks are processed one by one in FIFO order.

When event functions are triggered via the multicast route (e.g. storage and auth triggers), Functions Emulator submits a task per function associated with the event to the work queue where each task makes call to the event function via its HTTP endpoint. Let's call this task an "invocation task".

When the Function Emulator receives an HTTP request for function invocation, it submits a new task to the work queue to handle the http request. Let's call this task a "http task".

So, a call to the multicast route begets zero or more "invocation task" (one per trigger). Each "invocation task" begets exactly one "http task".

The code today is written such that an "invocation task" will wait for the corresponding "http task" to complete.

In debug mode this causes the invocation task to wait forever - the "http task" is stuck behind its "invocation task" in the queue. It never has chance to be processed.

This PR proposes that "invocation task" doesn't wait for the corresponding "http task" to complete, effectively breaking the deadlock.

The result is that "invocation task" now fire-and-forget an "http task". AFAIK, this doesn't have any negative effect because "invocation task" didn't do anything with the result of the "http task" anyway.

Fixes #5008, #5050