[SourceGen] Additional $return case

[satvu]

Issue describing the changes in this PR

Case missed in PR #2098

Pull request checklist

• 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
• I have added all required tests (Unit tests, E2E tests)

Additional information

While it is recommended to use this pattern for an HttpTrigger function with multiple output bindings, the following code is still valid and works in the legacy generator:

  [Function("Function2")]
  [QueueOutput("myqueue", Connection = "Con")]
  public HttpResponseData Run2([HttpTrigger(AuthorizationLevel.Function, "get", "post")] HttpRequestData req)
  {
      var response = req.CreateResponse(HttpStatusCode.OK);
      response.Headers.Add("Content-Type", "text/plain; charset=utf-8");

      response.WriteStringAsync("Welcome to Azure Functions!");

      return response;
  }

It produces the following metadata:

  {
    "name": "Function2",
    "scriptFile": "LegacyGeneratorTestApp.dll",
    "entryPoint": "FunctionApp4.Function2.Run2",
    "language": "dotnet-isolated",
    "properties": {
      "IsCodeless": false
    },
    "bindings": [
      {
        "name": "req",
        "direction": "In",
        "type": "httpTrigger",
        "authLevel": "Function",
        "methods": [
          "get",
          "post"
        ],
        "properties": {}
      },
      {
        "name": "$return",
        "direction": "Out",
        "type": "queue",
        "queueName": "myqueue",
        "connection": "Con",
        "properties": {}
      }
    ]
  }

Updating the source generator to reflect/include this case.

[fabiocav]

Is this even a valid case? What would be the expectation for what gets persisted in the queue here? Looking at the code would lead me to believe it would be the serialized HttpResponseData

[satvu]

I didn't think it was a valid case, but when I tested it against the legacy generator it does not produce any errors on generation or startup - as discussed offline, will table this for validation and potentially raise an error for this pattern in both generation methods.