You mentioned 3 issues being solved by this PR, but I don't see any new tests, only updates to existing golden files and output changes. Are those issues covered by existing tests?
If so, how did we not catch it before? (no blaming here) Were golden files too complex to analyze?

as for backporting. It's a significant change, but it's scoped to MeshPasshtrough so I'm ok with backporting it.

You mentioned 3 issues being solved by this PR, but I don't see any new tests, only updates to existing golden files and output changes. Are those issues covered by existing tests? If so, how did we not catch it before? (no blaming here) Were golden files too complex to analyze?

I think 2 main things

• complex dump
• not enough edge cases

The problem is that if the configuration is small we cannot hit some route aggregation/protocol ordering, but when is too big we might miss something. Maybe more targeted test cases could help here

Another edge case, in which network request to 10.42.0.7:80 was captured by the MeshPassthough policy one:

apiVersion: kuma.io/v1alpha1
kind: MeshPassthrough
metadata:
  name: one
  namespace: kuma-system
  labels:
    kuma.io/mesh: default
spec:
  targetRef:
    kind: Mesh
  default:
    passthroughMode: Matched
    appendMatch:
      - port: 80
        protocol: http
        type: Domain
        value: "www.gmail.com"
---
apiVersion: kuma.io/v1alpha1
kind: MeshPassthrough
metadata:
  name: two
  namespace: kuma-system
  labels:
    kuma.io/mesh: default
spec:
  targetRef:
    kind: Mesh
    proxyTypes:
      - Sidecar
  default:
    passthroughMode: Matched
    appendMatch:
      - protocol: http
        type: IP
        value: "10.42.0.8"

Do we have a test case that covers the case: #12054 (comment) ?

Do we have a test case that covers the case: #12054 (comment) ?

Yes, I split the big test case into smaller ones for readability