add Ports/NodePorts fields in GatewayServer and enforce (Node)Port/(Node)Ports coherence

[MircoBarone]

Description

Part of the multi-tunnel WireGuard implementation. This is the 4th PR related to issue #3225.

The Ports and NodePorts fields were introduced in GatewayServer:

• Ports stores the list of WireGuard listen ports that the gateway server uses internally, one per Wireguard interface.
• NodePorts is an optional list of ports used to expose the interfaces externally via the Kubernetes Service.

Like in the previous PR, (Node)Ports is not meant to replace the legacy (Node)Port field, which is kept for backward compatibility. The invariant is that (Node)Ports[0] must always be equal to (Node)Port.

A function analogous to the previous PR's EnsurePortsCoherence was added to the ServerReconciler. At the beginning of each reconcile cycle, it checks whether (Node)Port and (Node)Ports are consistent and normalizes them according to the following rules:

• If only (Node)Port is specified, (Node)Ports is set to []int32{(Node)Port}
• If (Node)Ports is specified, (Node)Port is overwritten with (Node)Ports[0]
• If neither is specified, both are set to the default value (applies to Port/Ports only — NodePort/NodePorts are optional and have no default)

After normalization, the resource is updated and the reconcile cycle is requeued.

Note that NodePorts may be shorter or longer than Ports. The intended behavior during Service creation is:

• If NodePorts is shorter, the remaining interfaces are exposed on ports chosen by Kubernetes
• If NodePorts is longer, the extra entries are ignored

numInterfaces, mentioned in the issue, was intentionally not introduced to keep GatewayServer simple and avoid an additional source of truth with potential inconsistencies. Future extensions may include:

• Specifying numInterfaces and auto-generating the missing ports
• An external utility, possibly integrated into liqotech peer, to generate ports given a desired count

[adamjensenbot]

Hi @MircoBarone. Thanks for your PR!

I am @adamjensenbot.
You can interact with me issuing a slash command in the first line of a comment.
Currently, I understand the following commands:

• /rebase: Rebase this PR onto the master branch (You can add the option test=true to launch the tests
  when the rebase operation is completed)
• /merge: Merge this PR into the master branch
• /build Build Liqo components
• /test Launch the E2E and Unit tests
• /hold, /unhold Add/remove the hold label to prevent merging with /merge

Make sure this PR appears in the liqo changelog, adding one of the following labels:

• feat: 🚀 New Feature
• fix: 🐛 Bug Fix
• refactor: 🧹 Code Refactoring
• docs: 📝 Documentation
• style: 💄 Code Style
• perf: 🐎 Performance Improvement
• test: ✅ Tests
• chore: 🚚 Dependencies Management
• build: 📦 Builds Management
• ci: 👷 CI/CD
• revert: ⏪ Reverts Previous Changes

[MircoBarone]

As done for PR #3233, I have moved the validation logic for (Node)Port = (Node)Ports[0] from server_controller.go to CEL-based validation within the CRD.
As I explained in that thread, this method can still be problematic if used with an improper template.
Please let me know if you consider this CEL validation sufficient or if you believe a Mutating Webhook is necessary.