* Xtls: code refactor
- Move more logic to VisionReader/Writer
- Remove XtlsWrite()
- XtlsRead now only handle splice at the outbound
- This helps VLESS inbound to have simple buf.copy() so that we can remove pipe next
* Add bufferFlushNext; Use DispatchLink() in VLESS inbound
* Use TimeoutWrapperReader; clean up timer/buffer
* Add GetInboundUser in proto
* Add get user logic for all existing inbounds
* Add inbounduser command
* Add option to get all users
* Fix shadowsocks2022 config
* Fix init users in shadowsocks2022
* Fix copy
* Add inbound user count command
This api costs much less than get inbound user, could be useful in some case
* Update from latest main
* Refactor log
* Add new log methods
* Fix logger test
* Change all logging code
* Clean up pathObj
* Rebase to latest main
* Remove invoking method name after the dot
* Add session context outbounds as slice
slice is needed for dialer proxy where two outbounds work on top of each other
There are two sets of target addr for example
It also enable Xtls to correctly do splice copy by checking both outbounds are ready to do direct copy
* Fill outbound tag info
* Splice now checks capalibility from all outbounds
* Fix unit tests
- Vision now use traffic states to capture two-way info about a connection
- XTLS is de-couple with Vision, it only read traffic states to switch to direct copy mode
- fix a edge case error when Vision unpadding read 5 command bytes
- Add outbound name
- Add outbound conn in ctx
- Refactor splice: it can be turn on from all inbounds and outbounds
- Refactor splice: Add splice copy to vless inbound
- Fix http error test
- Add freedom splice toggle via env var
- Populate outbound obj in context
- Use CanSpliceCopy to mark a connection
- Turn off splice by default
* Vision server allow multiple blocks of padding
* Fix Vision client to support multiple possible padding blocks
* Vision padding upgrade
- Now we have two types of padding: long (pad to 900-1400) and traditional (0-256)
- Long padding is applied to tls handshakes and first (empty) packet
- Traditional padding is applied to all beginning (7) packets of the connection (counted two-way)
- Since receiver changed its way to unpad buffer in fd6973b3c6, we can freely extend padding packet length easily in the future
- Simplify code
* Adjust receiver withinPaddingBuffers
Now default withinPaddingBuffers = true to give it a chance to do unpadding
* Fix magic numbers for Vision
Thanks @H1JK
Thanks @RPRX for guidance
In the past, when user open xtls vision on the server side, plain vless+tls can connect.
Pure tls is known to have certain tls in tls characters.
Now server need to specify "xtls-rprx-vision,none" for it be able usable on the same port.
