SplitHTTP client: Fix xmux config deserialization

[mmmray]

During the rename, it seems the parameters were defined with the wrong visibility, which means they are always deserialized as nil. Basically xmux doesn't work right now in the latest release due to this.

[RPRX]

正好我想了一下，都默认为 0 的话无限复用实际上是 maxConcurrency 主导的，所以应当把它放到 maxConnections 上面

@Fangliding 文档也改下顺序

[RPRX]

所以应当把它放到 maxConnections 上面

@mmmray

[RPRX]

proto 序号

[RPRX]

@Fangliding 文档需要更新：

1. “默认行为为将所有请求复用至一条 TCP/QUIC 连接。”
2. mux.cool 那行的描述不太对，整行改为“由于默认是无限复用，xmux 实际上是对此进行限制。此外不要启用 mux.cool。”
3. maxConcurrency 整段移到 maxConnections 上面

[Fangliding]

@Fangliding 文档需要更新：

1. “默认行为为将所有请求复用至一条 TCP/QUIC 连接。”
2. mux.cool 那行的描述不太对，整行改为“由于默认是无限复用，xmux 实际上是对此进行限制。此外不要启用 mux.cool。”
3. maxConcurrency 整段移到 maxConnections 上面

有点点哭笑不得 maxconcurrency我昨天就改掉了 但是没改上面的config实例部分 后来mmm也来改了 把config示例和下面的解释一起对调了 结果就是config示例对了但是下头我换上来的 maxconcurrency又被换下去了 今早检查的时候还纳闷怎么昨天编辑了怎么没变

对于一个有默认行为的机器 插入一个可选controller对其行为进行更精细的控制不少作品其实都有 很少有把它叫limit的（虽然有时候确实是这个作用） 所以我之前写的时候没提

其实h2复用也不是无限的 golang默认最大stream好像是100 而且这个控制器的流扫过一眼discussion这个concurrency好像不是控制的具体h2流而是整个splithttp 它产生的http请求肯定不止一条 最少也是两条 所以真正的concurrency可能也就几十？

[RPRX]

其实h2复用也不是无限的 golang默认最大stream好像是100

你深究一下，可能需要改掉，不过不知道那些反代软件有没有限制，你查一下