Try MeshLoadBalancingStrategy with MeshMultizoneService

[bartsmykla]

Description

We should try MeshLoadBalancingStrategy with MeshMultizoneService as it should behave differently that we should prioritize local zone instead of prioritizing splitting traffic between all zones.

This is followup for: #11966

[lukidzi]

Additionally, we need to ensure that when a user disables locality-aware routing using MeshLoadBalancingStrategy, traffic is properly distributed across zones.

[michaelbeaumont]

we should prioritize local zone instead of prioritizing splitting traffic between all zones.

btw this is already the case

[github-actions]

Removing closed state labels due to the issue being reopened.

[lahabana]

Fix was reverted in:

• Revert "fix(MeshLoadBalancingStrategy): set all priorities equal if localityAware is disabled" #11984

[lukidzi]

We have two options to set locality-aware load balancing in Kuma:

1. Mesh: Locality-Aware Load Balancing
2. MeshLoadBalancingStrategy (MLBS): Locality Awareness in MLBS

These options allow control over whether traffic should be split across different zones or prioritized within the local zone.

• MeshService: Prioritizes the local zone.
• MeshMultiZoneService: Prioritizes the local zone.
• kuma.io/service: Sets the default priority to 0, distributing traffic across different zones.

When the locality-aware flag is enabled on the Mesh, traffic for kuma.io/service will remain within the same zone. The same effect occurs with MLBS: when set to true, traffic stays within the local zone. If both sets, MLBS can override it

[michaelbeaumont]

@lahabana @lukidzi do we have any action to take given the above? or can we close this again

Note: The fix was not reverted, instead #11987 was the issue

[lukidzi]

I think there is one more thing to try, we should check how we behave by the default (no policy/lb mesh configured)

[michaelbeaumont]

For this we have an e2e test I think right? It's locality aware

[lahabana]

Putting this back in pending so we discuss this