[main] destination-port/app-port should be configurable in map-route like with the new beta flag for destination-protocol/app-protocol #3613

[mauricebrinkmann]

Description of the Change
This PR introduces support for setting the route destination port via the CF CLI map-route command using a new app-port parameter. This functionality is comparable to the existing app-protocol parameter used for setting the destination protocol.
The change enables users to specify the destination port directly when mapping a route to an application.

Why Is This PR Valuable?
This change improves the flexibility of the map-route command by allowing users to configure the destination port for their routes directly from the CLI. This is particularly valuable for applications that require traffic to be routed to specific, non-default ports, aligning the CLI's capabilities with the underlying networking features.
Especially this is useful for docker apps that have multiple ports, where the end user needs to switch tools to configure it via API oder Terraform instead of just using cf push from the command line as long as the CLI and the manifest do not support setting it.

Applicable Issues

• destination-port/app-port should be configurable in map-route like with the new beta flag for destination-protocol/app-protocol #3613

How Urgent Is The Change?
This change is a feature enhancement and not time-sensitive.

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: mauricebrinkmann / name: Maurice Brinkmann (05700b9, 0ef49ed, 34ead02, bf4e439, ec2a8bd)

[mauricebrinkmann]

sorry wrong repo

[mauricebrinkmann]

meant to create this one first: funcf#1 with a slick description
and then planned to create an issue first, before raising a proper PR here.

[mauricebrinkmann]

created #3613 for this.

[mauricebrinkmann]

I had another look at the PR and worked on the integration tests.
However, appreciate any feedback, even if it is saying that we should not change the routes table, as such an integration test breaking change might also break some customer processes and pipelines, when parsing the cli output in a similar way (e.g. with awk scripts).
So I am open to revert the presentation as the destination port would be 8080 for most buildpack apps anyways and it can also be seen when querying the route with "cf route <route_name>". My thought was just that for apps with multiple ports, if would be really cool to see which route goes where - like in the Kong API Gateway docker container example screenshots here #3613 or the following NodeRED docker container example:

> cf routes
Getting routes for org MauriceExternal / space prod as maurice.brinkmann@stackit.cloud...

space   host             domain                          port   path   protocol   app-protocol   apps             service instance   options
prod    docker-nodered   apps.01.cf.eu01.stackit.cloud                 http       http1          docker-nodered
prod    new-nodered      apps.01.cf.eu01.stackit.cloud                 http       http1          docker-nodered
prod    bad-nodered      apps.01.cf.eu01.stackit.cloud                 http       http1          docker-nodered
 
VS.
 
> out/cf routes
Getting routes for org MauriceExternal / space prod as maurice.brinkmann@stackit.cloud...

space   host             domain                          port   path   protocol   app-protocol   app-port   apps             service instance   options
prod    docker-nodered   apps.01.cf.eu01.stackit.cloud                 http       http1          1880       docker-nodered
prod    new-nodered      apps.01.cf.eu01.stackit.cloud                 http       http1          1880       docker-nodered
prod    bad-nodered      apps.01.cf.eu01.stackit.cloud                 http       http1          8080       docker-nodered

[mauricebrinkmann]

I have to touch the tests again as I oversaw the header rows...