Allow for an output binding value of an invocation result to be null

[satvu]

Issue describing the changes in this PR

Part of the fix for Azure/azure-functions-dotnet-worker#2682, related to Azure/azure-functions-dotnet-worker#2896.

Allows for output binding values to be null, which is interpreted as the type ParameterBinding.None when receiving the values over gRPC.

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)

Additional information

Here is the original PR adding the switch statement. The logic was originally added to differentiate between data transferred by the worker using shared memory vs RPC. It doesn't appear to purposefully prevent output bindings from having a null value.

Invocation results are nullable (see here), and the HTTP Proxying design sends a null result over the gRPC pipeline.

[kshyju]

Is this a breaking change for customers?

[satvu]

Is this a breaking change for customers?

I don't believe this will break existing customers explicitly. It will allow for a successful invocation to have an output binding with a null value. Without this change, the scenario would throw an exception.

I think that currently, cases where we can expect null output binding values are usually when invocations fail, and that is handled in a different code path starting from here.

This could definitely open the door for some new scenarios though. If a customer expects to have a value for their output binding but their function invocation status is "successful" despite an erroneous null value, this could break another one of their components.