Checklist prior to review

Do not merge for release-2.9. I'd rather put it in 2.10

We use x-kuma-tags internally. We add this to outbound HTTP listeners and we remove them on the inbound listeners. Currently, we use this header for 3 things

1. Match sources in FaultInjection policy
2. Match from in MeshFaultInjection policy
3. Match sources in RateLimit policy

I'd argue that in 99% cases you don't need it then.
Just a simple app on Kube looks like this

            "request_headers_to_add": [
              {
                "header": {
                  "key": "x-kuma-tags",
                  "value": "&app=redis&&k8s.kuma.io/namespace=kuma-demo&&k8s.kuma.io/service-name=redis&&k8s.kuma.io/service-port=6379&&kubernetes.io/hostname=k3d-kuma-server-0&&kuma.io/protocol=tcp&&kuma.io/service=redis_kuma-demo_svc_6379&&kuma.io/zone=default&&pod-template-hash=686bbbb5c8&"
                }
              }
            ],

This is quite a lot of data to put on every single request between Envoys.
Additionally, that's quite a lot of data to put on every single outbound in XDS config. Removing this slims down the XDS config.

Long term this header should be deleted and we should extract this from the certificate on the inbound side.

• Link to relevant issue as well as docs and UI issues --
• This will not break child repos: it doesn't hardcode values (.e.g "kumahq" as a image registry) and it will work on Windows, system specific functions like syscall.Mkfifo have equivalent implementation on the other OS --
• Tests (Unit test, E2E tests, manual test on universal and k8s) --
  • Don't forget ci/ labels to run additional/fewer tests
• Do you need to update UPGRADE.md? --
• Does it need to be backported according to the backporting policy? (this GH action will add "backport" label based on these file globs, if you want to prevent it from adding the "backport" label use no-backport-autolabel label) --