Freedom: Add maxSplit fragment option; Add applyTo noises option

[patterniha]

1. Fragment option maxSplit

in fragment, the size of each received packet is uncontrollable, so if a packet is small, the number of splits is low, and as a result, the delay and number of send-packets are also low.

but if a packet is large, we will have a lot of delays and a lot of split-packets will be sent, This is because we have no control over the number of splits for large packets.

for example in this config:

"fragment": {
          "packets": "1-1",
          "length": "1",
          "interval": "1"
}

if request is curl-tls-client-hello, request size is 517 bytes, so we have 517 split-packets and 517ms delay, and this is acceptable, but if request is chrome-tls-client-hello or other unknown protocol, the request size is big, so the delay and number of send-packets will be too much.

so I add maxSplit to control number of splits. also for bypassing GFW, it is enough that the number of splits is more than 100, for example.

for above config, for example, if request size is 100 bytes, and we set maxSplit to 50, we send 49 1-bytes-packet with one 51-bytes-packet.

so the number of splits will never exceed maxSplit(after the number of splits reaches maxSplit, the rest of the packet-bytes is sent without fragmentation)

"fragment": {
          "packets": "1-1",
          "length": "1",
          "interval": "1"
          "maxSplit": "100-200"
}

////////////////////////////////////////////////////

2. Noise option applyTo

chrome-quic-fingerprint depends on the type of destination IP.(unlike tcp-tls, which is independent of IP type)

chrome initial-quic-packet-size is 1250 bytes when sent to an IPv4 address, and it is 1230 bytes when sent to an IPv6 address.(this is because of concerns about MTU)

Although we don't have fake-quic-noise yet, but users can manually define noises, and for different types of IP, they should set the appropriate noises.

we cannot set two different outbounds, one for IPv4 noises, and one for IPv6 noises, because target address can be a domain, and the IP-type is only determined after dial, so we cannot route base on IP-type, as a result this option is necessary.

for example for:

{"type": "str", "packet": "a", "applyTo": "ip"},
{"type": "str", "packet": "b", "applyTo": "ipv4"},
{"type": "str", "packet": "c", "applyTo": "ipv6"}

we send "a", "b" when remote address is IPv4, and send "a", "c" when remote address is IPv6.

///

maxSplit: Int32Range

applyTo: string --- "ip"(default) / "ipv4" / "ipv6"