Implement registry-proxy for simplifying DNS interdomain usage

[denis-tingaikin]

Closes networkservicemesh/deployments-k8s#9318
Closes networkservicemesh/deployments-k8s#8343

Description

We could extreamly simplify current interdomain logic with adding a new control plane registry component. In fact, this component already exists and is currently a sidecar to the proxy manager https://github.com/networkservicemesh/sdk/blob/main/pkg/networkservice/chains/nsmgrproxy/server.go#L272-L316

Currently, we're using two DNS entries for interdomain scenario https://github.com/networkservicemesh/sdk/blob/main/pkg/registry/common/dnsresolve/common.go#L35-L38

It goes from the fact that we should have two entry points for two kinds of requests (network connection, registry ns/nse). Also, sinse nsmgr-proxy implements registry service by current arch that registry could work only for outbound traffic. By this reason we're using two lookups(because we cant do inbound lookup into registry server of nsmgr-proxy at this moment).

instead of two external service we can use one - registry service.

In case of floating scenarious by registry service will be used any registry with entries. For example registry-memory.
In other cases by registry service could be used registry-proxy.

The trick of reducing services is that registry-proxy could simply replace for outbout requests the nse.url to the external node ip.

Changes

nsmgr-proxy

-- do not implement registry server interface.
--remove ton of code related to interdomainybpass https://github.com/networkservicemesh/sdk/blob/main/pkg/registry/common/interdomainbypass/server.go

new app registry-proxy

++ true inbound/outbound interdomain registry
++implements registry server interface
++in case of registration/unregistration it replaces url to the current nsmgr-proxy and proxies all trafic to the registry-proxy-$discovery-system (i.e. dns)
++ in case of find it proxies all trafic to the registry-proxy-$discovery-system (i.e. dns) and if it detects that nse.url is eq to the current nsmgr-proxy url than it translates request to the local (it also solves networkservicemesh/deployments-k8s#8343 and networkservicemesh/deployments-k8s#9318)

Scheme

https://drive.google.com/file/d/1Il3lgJdscjngXT2LMJyVHHh0eFlHITCJ/view?usp=sharing

Pros/Cons

Pros:

1. Simplifies interdomain logic (no more huge overthinking compomnents like nsmgr-proxy that currently implements registry/networkservice interfaces)
2. Reduces exposed services count from two to one.
3. Resolves known issues that causedby current architecture limitations (In multi-cluster scenarios specifying @cluster in netsvc name doesn't work on the same cluster deployments-k8s#8343 and Interdomain (2 cluster) setup uses different readme structure compared to other NSM example setups deployments-k8s#9318)
4. Reduces DNS usage from two requests to one.

Cons:

1. Adds a new app.

TODO

• Investigration / Planning / Drawing ~ 9h
• Rework SDK chain elements ~ 15h
• Add chains/registry-proxy ~8h
• Make all sdk test work ~12h
• Implement cmd-registry-proxy ~ 4h
• Run/Fix all exsist interdomain tests on k8s ~ 12h
• Add local interdomain example ~ 4h
• Pass CI / Linter / Review ~ 4h

TOTAL: 67h