feat(envoyadmin): support passing kds envoy operations via http proxy

[jakubdyszkiewicz]

Checklist prior to review

The current assumption was that Zone CP connects to one instance of Global CP in order to exchange KDS information as well as execute Envoy Admin operations.
We can see it here we call one grpc.Dial and then start streaming services on this TCP connection.

However, we recently provided an option to disable TLS on Global CP server which means that you may want to have an HTTP reverse proxy in front of Global CP. In this case, HTTP proxy will loadbalance gRPC streams between all instances of Global CP, which means that the assumption that global instance that's handling KDS == global instance that's handling envoy admin rpc streams is wrong.

To fix this, we need to store an instance that's handling each envoy admin rpc stream.

• 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) -- It's quite hard to add E2E for this and it would require implementing it in legacy suite, which we try to avoid.
• Do you need to update UPGRADE.md? --
• Does it need to be backported according to the backporting policy? -- no
• Do you need to explicitly set a > Changelog: entry here or add a ci/ label to run fewer/more tests? no

[slonka]

LGTM just trying to wrap my head around the fact that we need to keep separate xds / stats / clusters info. Also should we add an issue to have an e2e tests of this?

[jakubdyszkiewicz]

Also should we add an issue to have an e2e tests of this?

I'm not sure... test for it will be quite costly, we need separate multizone deployment to check this out