Handle null and undefined values of result and result.return in invocationRequest

[davidmrdavid]

This PR addresses this issue in the Durable JS SDK.
Previously a "falsy" return value would fail to serialize due to logic in invocationRequest that led the worker to assume that there was no return value.

This PR simply refines some if-statements to ensure we only avoid serialization when result and result.return are either null or undefined. :)

ToDos:
I was hoping to add at least one unit test to this, but I couldn't figure out a way to set result variable here by looking at the WorkerChannel tests. Any ideas, pointers, or examples I could follow? Thanks!

[mhoeger]

Thanks David! I would try adding a test just like this one: https://github.com/Azure/azure-functions-nodejs-worker/blob/v2.x/test/WorkerChannelTests.ts#L445-L456

Although this is definitely a bugfix, since the current behavior has been in place for so long I wonder if it counts as a breaking change and something we should be careful about? I'm trying to think about the impacts a change here may have on a customer's system, and I think it may depend on the type of binding (ex: if it's an HTTP output, honoring a "false" value might return something different or if it's a blob output maybe "0" means that no blob is output, or something like that). @fabiocav - any thoughts on this bugfix and potential breaking impact?

[davidmrdavid]

@fabiocav, could we get your thoughts Marie's question above?

[fabiocav]

This is indeed a breaking change and has the potential to negatively impact production workloads with a behavior change.

I agree that it is a good change, but likely behavior that would need to be put behind a flag until we have a new major version out.