Revert "Avoid setting --port twice for Azure Functions (#7683)"

[JamesNK]

This reverts commit 97d5c1c.

Change is no longer neccessary with #7711

Confirmation that double args aren't shown:

From Azure Functions EndToEnd sample.

[Copilot]

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

Comments suppressed due to low confidence (2)

src/Aspire.Hosting.Azure.Functions/AzureFunctionsProjectResourceExtensions.cs:120

• There is an inconsistency between the publish mode check here and the one in the removed block that uses 'builder.ApplicationBuilder.ExecutionContext'. Consider revisiting which property should be used to ensure consistent behavior.

if (builder.ExecutionContext.IsPublishMode)

tests/Aspire.Hosting.Azure.Tests/AzureFunctionsTests.cs:53

• The test now expects a null TargetPort rather than a specific port value; please verify that this change correctly reflects the intended behavior of the port-mapping logic.

Assert.Null(endpointAnnotation.TargetPort);

[JamesNK]

Note: This change isn't in release/9.1. No need to backport this PR.

[eerhardt]

Are we sure we should be reverting this change? From @captainsafia on #7653 (comment)

Hmmm...I see. I think the change on the Functions side is still valid since we shouldn't be populating args at all if we don't need to.

[JamesNK]

There is no urgency is merging this. Will wait until David, Safia have commented.

[captainsafia]

Let's not merge the revert. Although the DCP issue was the root cause, this was still exposing a place where we were setting the --port redundently.

It also happens that I need to move the WithArgs to the WithFunctionsHttpEndpoint for some launch profile-based processing for HTTPs so this is a code move that would've happened anyways.

[davidfowl]

See #7751

[captainsafia]

See #7751

Posted a comment on this. I don't think reverting my change solves this. It seems like there's a different change that is causing the -- to be inserted here.