Global HTTP headers' masquerading: Add "curl"; Improve version generators

[PoneyClairDeLune]

This PR added version generators for cURL, Firefox and Safari, as well as realistic headers for each. The RNG has also been migrated to become global.

The newer version generators still use randomized distributions, however it's now more deterministic, with a single setback scaled by a natural tailed curve, simulating common version distribution graphs.

I do suggest that the Chrome version generator should use the exact same approach to avoid version distribution avalanche caused by normal distribution. The current implementation of the Chrome version generator does not correlate well with the actual browser version distribution.

[RPRX]

Chrome 那个是我临时搞的，你觉得这个更好的话也换成这个吧

[PoneyClairDeLune]

Just added Chrome to the party, all scaled with exponentials.

[RPRX]

这个你检查过符合各个浏览器的发版规律吧，当初我搞 Chrome 那个时发现它偶尔会“休息”一个月，当初考虑到了这种情况

[RPRX]

#5658 (comment) 25-45 天就是这么来的

[PoneyClairDeLune]

@RPRX I did a statistical counting from Chrome 127 all the way to 147. The average release duration counting all the delays is 31.15 days, although I might as well increase the average cycle to 32 just in case.

{28, 28, 28, 42, 35, 28, 28, 28, 42, 28, 28, 28, 28, 28, 21, 63, 28, 28, 28, 28}

[RPRX]

你要取 avg 的话极容易出现“未发布的版本”，#5658 (comment) 这里也说了可以每年修正下

[RPRX]

就是说 Chrome 还是按 avg=35 来算吧，其它浏览器也是改成 avg 加几天

[PoneyClairDeLune]

@RPRX Not really, however that will rely on the fixed setback to do the work. The current maximum is 63 days out of the 31.25 day average, a fixed setback of at least 32 day will currently sidestep the problem. Although I admit that having a single version ahead of normal stable release schedule will not be that suspicious, the exponential curve could amplify that.

Although there could be a better modelling curve for Chrome than the exponential curve. I probably need to look at some more curves to see which offers a skewed bell.

Edit: Replied too late.

[PoneyClairDeLune]

So 35 days for Chrome and 30 for Firefox.

The current version generator of Safari (macOS and iOS seem to be the same, however Safari on iOS sends headers unpredictably) is heavily reliant on calendar instead of duration like the real deal, and it is pretty conservative based on most edge case observations.

[RPRX]

保守点好，可以合并了吗

[PoneyClairDeLune]

I think it is now ready for merging.

[RPRX]

比起这个假的，真的 #5419 #3840 有进展吗

还有个问题，XHTTP 的 packet-up 模式在任何浏览器上都能工作，Chrome 理论上还支持 stream-up，现在的代码是支持的吗

[PoneyClairDeLune]

@RPRX Streamed upload is a "yes" in theory, however it wasn't properly tested before updates to HTTP-based transports landed, so I have no idea if simply merging the changes to the current codebase will work.
Appat (name of the stream-only dialer) right now can interface and function with other programs without any error, but if support for non-Chromium browsers (browsers that don't support streaming) is required, it will not work until I can add fallback modes to those browsers.

[Fangliding]

仍然无法解决最大6个ws连接的问题

[RPRX]

仍然无法解决最大6个ws连接的问题

浏览器的 WS 连接数限制不是最大 256 吗

[Fangliding]

per host

[RPRX]

per host

就是 per host，至少 Chromium 是这样，不然初版 browser dialer 不会那么奢侈的，而且似乎换个端口还重新计算