Improve the logic to generate TLS-based container ports by the Quarkus Kubernetes extension

[Sgitario]

Description

At the moment, the Quarkus application uses some runtime properties to configure the TLS configuration. For example:

• quarkus.http.ssl.* to configure the HTTP TLS server
• quarkus.management.ssl.* to configure the Management TLS server

The problem is that some of the above properties need to be known at build time by the Quarkus Kubernetes extension to properly generate/bind the HTTPS/management ports.

Tasks

• For the HTTP TLS configuration, add a new property quarkus.kubernetes.ports.https.tls=true with default value false. If users set it to true, then the container port HTTPS will be bound to the application container and to the service resource. If false, we will check whether the quarkus.http.ssl.* runtime properties were set at build time using the ConfigProvider API, and bind the container HTTPS accordingly. Do not generate the https in K8s unless HTTP ssl configuration is set #33696
• For the Management TLS configuration, we will do the same as above but with the property quarkus.kubernetes.ports.management.tls=true. Fix K8s/OpenShift deployment when using management interface+https #32902
• The Quarkus Kubernetes extension will print some INFO logs saying that some runtime properties were used and can't change when running the application. For example: quarkus.http.port. Print messages about ports that can't change at runtime for K8s #33789
• The Management port should never be bound into the generated Service resource: Do not bind the Management port into the generated Service resource #33694

[quarkus-bot]

/cc @geoand (kubernetes), @iocanel (kubernetes)

[Sgitario]

cc @cescoffier

[Sgitario]

Closing epic since all the sub-tasks were completed