[Enhancement] Allow custom path and stream name for gRPC

[HirbodBehnam]

We had a talk with @RPRX in #1790 about allowing custom paths in gRPC transport.
There is a recap of our idea.

1. We can assign custom stream names for Tun and TunMulti. These strings are currently hardcoded here. Changing them shouldn't be a big deal.
2. Allow user to use absolute paths for gRPC. This can be determined from the prefix of / in serviceName. But this will bring us a problem. How we are going to distinguish traffic with multiMode set and not set?

I think implementing 1 is pretty simple and straight-forward. For 2, we can do this:

1. Check if serviceName has / suffix. If it does not have one, just act like before.
2. If it does have, we don't path escape the serviceName. Instead, we will use absolute path defined in the serviceName + the custom Tun and TunMulti stream name. For example if the serviceName is set to /my/path and our custom Tun stream name is customTun, we will send our request to www.hostname.com/my/path/customTun. On the client side, this looks easy to implement. The implementation should take place in this file again. However, on the server side we should make sure that the gRPC library does support paths as its service name.

[RPRX]

For server:

{
    "serviceName": "/my/path/customTun,/my/path/customTunMulti"
}

For client:

{
    "serviceName": "/my/path/customTun",
    "multiMode": false
}

{
    "serviceName": "/my/path/customTunMulti",
    "multiMode": true
}

[RPRX]

有时间写一下这个功能吗？其实在提出 #1790 (comment) 之前我尝试改过，好像会有些问题，但最近我没有太多的时间去测试它。

[HirbodBehnam]

I can try to sketch something...

[HirbodBehnam]

I've investigated a little. It seems that it's not possible to make the beginning of the path different. For example I cant define the service name as this on server:

{
    "serviceName": "/my1/path/customTun,/my2/path/customTunMulti"
}

If we want to do this, we need to register two different service's with different service names. But we also need to define two different stream names for each service. One for TunMulti and other for Tun. Also we may want to use a HTTP mux instead of raw service name but that also has down sides. Like probably can make the server more distinguishable.
One other thing which can probably be done is that we can force users to have the first part of their service name for Tun and TunMulti to be same. With this, we can probably use the same part as the service name and the other part as the stream name.

[RPRX]

One other thing which can probably be done is that we can force users to have the first part of their service name for Tun and TunMulti to be same.

这个是可以接受的，其实自定义 path 主要是为了：

1. 套 CDN 或部署在一些 Serverless 容器平台时，/Tun 和 /TunMulti 过于明显，需要允许自定义，以避免平台据此限流、封禁
2. 支持更加灵活的 path 分流，尤其是破坏性的，比如原始 path 为 /prefix/abc，经 /prefix 分流后，Xray 只能接收到 /abc

[HirbodBehnam]

I see. I'll try to sketch something for this...

[HirbodBehnam]

I've made some changes in this branch of my fork.
I just did what we discussed together. For now, There is no config validator. I'll do that after we have confirmed that everything works fine. I tested it using this config:
Server:

{
    "log": {
        "loglevel": "debug"
    },
    "inbounds": [{
            "listen": "127.0.0.1",
            "port": 12345,
            "protocol": "trojan",
            "settings": {
                "clients": [{
                        "password": "123456"
                    }
                ]
            },
            "streamSettings": {
                "network": "gun",
                "security": "none",
                "grpcSettings": {
                    "serviceName": "/my/sample/path/t1,/my/sample/path/t2"
                }
            }
        }
    ],
    "outbounds": [{
            "protocol": "freedom"
        }
    ]
}

Client:

{
    "log": {
        "loglevel": "debug"
    },
    "inbounds": [{
            "listen": "127.0.0.1",
            "port": "10818",
            "protocol": "socks"
        }
    ],
    "outbounds": [{
            "protocol": "trojan",
            "settings": {
                "servers": [{
                        "address": "127.0.0.1",
                        "port": 12345,
                        "password": "123456"
                    }
                ]
            },
            "streamSettings": {
                "network": "gun",
                "security": "none",
                "grpcSettings": {
                    "serviceName": "/my/sample/path/t1",
                    "multiMode": false
                }
            }
        }
    ]
}

And executed curl -v -x socks5://127.0.0.1:10818 api.ipify.org in another terminal to see if the proxy works fine.

I also changed the logs to print info about the service/stream name. We can change them if needed. Also if serviceName does not have / as the prefix, we simply fallback to previous implementation. Even stream names of Tun and TunMulti are preserved.

I'd be happy to hear your feedbacks!

[RPRX]

我查看了 gRPC 库的代码，服务端它是这样处理的：

https://github.com/grpc/grpc-go/blob/dba26e15a07f43875ccf806a2dd6cbcbc1c12eab/internal/transport/http2_server.go#L411
https://github.com/grpc/grpc-go/blob/dba26e15a07f43875ccf806a2dd6cbcbc1c12eab/server.go#L1674

所以“支持更加灵活的 path 分流”应该已经实现了，good job！

Also we may want to use a HTTP mux instead of raw service name

不是，看起来 gRPC 库可以自己处理。不过用同一个 service name 方便一些，那么服务端可以改成这样配置：

{
    "serviceName": "/my/path/customTun|customTunMulti"
}

[HirbodBehnam]

Nice. Happy to hear that!
That's also a very good way to define the service name. I'll add these to my fork and then I'll submit a PR. Maybe I add some simple unit tests as well...