Experimental support for Gateway API

[strekm]

Description

Extend Istio CRD with configuration to enable Gateway API. This configuration should only be available in experimental offering. In managed offering (fast, regular) it should not be possible to enable Gateway API. CR should be validated, set to Warning and configuration should not be applied. Consider introducing specific condition for it.

This configuration should be implemented as additional in Istio CRD spec, called experimental.

At this moment Istio supports 6 environment variables for Gateway API configuration. 4 of them are enabled by default. These ones do not need to be exposed in experimental configuration. PILOT_ENABLE_ALPHA_GATEWAY_API should be configurable, disabled by default. Research PILOT_MULTI_NETWORK_DISCOVER_GATEWAY_API and consider also exposing it under experimental spec.

ACs:

• it is possible to enable Gateway API for experimental offering
• Gateway API related documentation is marked as experimental
• Experimental implementation is not leaked to managed solution (Kamil's POC)
  - [ ] Gateway API UI is marked as experimental

Reasons

Enable alpha / beta feature in experimental offering

DoD:

• Provide unit and integration tests.
• Provide documentation.
• Provide ADR --> @barchw
• Verify if the solution works for both open-source Kyma and SAP BTP, Kyma runtime.
• If you changed the resource limits, explain why it was needed.
• If the default configuration of Istio Operator has been changed, you performed a manual upgrade test to verify that the change can be rolled out correctly.
• Verify that your contributions don't decrease code coverage. If they do, explain why this is the case.
• Add release notes.

Attachments
part of: #669
https://istio.io/latest/docs/reference/commands/pilot-agent/

[Ressetkk]

/assign

I suggest that instead of "experimental" the field is called alphaFeatures.

spec:
  alphaFeatures:
    pilot:
      gatewayAPI: true
(...)

With this approach it is easily expandable and contained in grouped list of features per Istio component.
Of course a good practice would also be that we somehow mention that specific version contains alpha features and that no SLAs are supported for this config.

I'd also be very cautious with building multiple docker images and how we generate them now. Ideally this should be handled in separate stage with Job Matrix and possibly use https://github.com/marketplace/actions/build-and-push-docker-images instead of the current flow.

[strekm]

I suggest that instead of "experimental" the field is called alphaFeatures.

@Ressetkk i'm more in favour of keeping experimental. it has connection to image name and distribution channel. other than that experimental API should be easily transferrable to regular API.