XHTTP server: Add scStreamUpServerSecs, enabled by default

[RPRX]

#4113 (comment) 的相关测试发现 CF 会掐断下行 100 秒无实际数据的 HTTP，导致 stream-up 的上行方向被掐断，所以这个 PR 为服务端添加了 scStreamUpServerSecs，默认值 "20-80" 取随机，服务端每隔这段时间就会发 xPaddingBytes 个字节以保活

这项机制只应针对新客户端（因为旧客户端会关闭连接），正好 #4298 是 breaking，基于 x_version 改为了基于 Referer header

可以设置 "scStreamUpServerSecs": -1 以关闭该机制，此时服务端甚至不会及时发 response header，和以前版本的行为相同

所以这个 PR 终于为 #4253 的事业划上了句号，并重新引入了 836e84b 的简单 recover，此外 xPaddingBytes 不再能被关闭
b786a50

NFT 半个月没动静了，你不捐我不捐，谁给你们开发 Xray，所以你懂的：

• ETH/USDT/USDC: 0xDc3Fe44F0f25D13CACb1C4896CD0D321df3146Ee
• Project X NFT: Announcement of NFTs by Project X #3633
• REALITY NFT: https://opensea.io/assets/ethereum/0x5ee362866001613093361eb8569d59c4141b76d1/2

[RPRX]

记录一下 https://t.me/projectXtls/621

XHTTP 新增 scStreamUpServerSecs，解决了 stream-up 上行方向无下行实际数据被 HTTP 中间盒掐断、长连接应用断线的问题：#4306

面向cf的限制编程

肯定要优先适配规模最大的 CDN，XMUX 的默认值还是适配 Nginx 的
并且这项机制是通用的，因为其它 HTTP 中间盒可能也有类似的行为

遥想几个月前我在注释写了一个cloudflare被要求删掉了 现在已经完全面向CF编程力

其实这个要求还是没变的，注释写上确实不合适，但是讨论一直都可以

还有我看了群里的讨论，不确定 CF 是不是只针对 gRPC 有这个 100 秒要求，可能 stream-down 即使下行 100 秒没数据也没事

[RPRX]

尤其是 stream-down 默认是 SSE header，（同时请求非 gRPC header 时）可能 CF 会区别对待它和普通 HTTP，不过这不重要