fix(protocol): support plain SIP002 SS userinfo for ss2022 URLTest

[snnabb]

Summary

This PR is now rebased onto the latest main (01b50b6) and only keeps the SS parsing fix.

It addresses two user-visible problems that share the same root cause:

1. Valid SIP002 SS links using plain URI-escaped userinfo fail to parse.
2. Affected ss2022 nodes then fail latency / URL tests, which makes them look like Mihomo does not support those links.

Root Cause

DecodeSSURL currently does an unconditional base64 decode on userinfo before splitting cipher:password:

• legacy form that still works today: ss://base64(cipher:password)@host:port
• plain SIP002 form that currently breaks: ss://cipher:password@host:port

For the plain SIP002 form, the current code decodes the already-plain userinfo again, so valid links such as ss://2022-blake3-aes-256-gcm:...@host:port are rejected before Mihomo ever gets a usable adapter.

In practice that shows up as two symptoms:

• node import / decode fails for valid plain-userinfo SS links
• Mihomo URLTest / latency test fails for those same ss2022 nodes, not because Mihomo necessarily lacks ss2022 support, but because the adapter creation path already failed in SublinkPro

Fix

• add decodeSSAuth to accept both SS auth encodings:
  • legacy base64 userinfo
  • plain URI-escaped cipher:password userinfo
• keep the previous base64 path unchanged when the auth really is base64
• correctly PathUnescape plain userinfo, so reserved characters are preserved
• keep passwords containing embedded colons intact after splitting only on the first colon

Tests

• add regression coverage for plain SIP002 userinfo
• add regression coverage for a password that itself contains a colon, which is common in ss2022 material
• go test ./node/protocol

Manual Validation On Latest Main

I reproduced this on the latest main first, then re-tested with this patch.

On the latest unpatched main, previously failing ss2022 sample links still timed out in real Mihomo URL tests because adapter creation failed first.

After applying this patch on top of the latest main, the same ss2022 samples passed URL testing successfully.

[ZeroDeng01]

已经有了ss_test,对应协议的测试内容集中在本协议对应的测试文件里面而不是针对某项功能专门增加test一个测试用例文件

[ZeroDeng01]

目前你的分支落后于 main 分支，为了确保代码在最新环境下运行正常，麻烦你将分支 rebase 到最新的 main 并解决可能存在的逻辑问题。谢谢！

[snnabb]

感谢回复，昨天在添加节点时发现的小问题，另外延迟测试时候有些协议是不是不支持，我测试ss2022中，128的支持，256的不支持，这个功能是否也在新版本已解决

[ZeroDeng01]

感谢回复，昨天在添加节点时发现的小问题，另外延迟测试时候有些协议是不是不支持，我测试ss2022中，128的支持，256的不支持，这个功能是否也在新版本已解决

延迟测试使用的mihomo内核，需要确认一下mihomo对ss2022的支持性相关问题诶！我这边没有ss相关节点进行测试所以无法确定具体问题所在。😔

[snnabb]

我昨天让codex帮我修复这个问题了，但是他好像没给提pr，等我晚上回家看看，可以的话再提一个pr可以吗

[ZeroDeng01]

我昨天让codex帮我修复这个问题了，但是他好像没给提pr，等我晚上回家看看，可以的话再提一个pr可以吗

欢迎pr!另外pr前记得rebase下main!

[snnabb]

okok

[snnabb]

Rebased onto the latest main and revalidated there before updating this PR.

This PR documents two user-visible failures with one shared root cause:

1. Valid plain SIP002 links in the form ss://cipher:password@host:port are decoded as if the userinfo were still base64.
2. The same affected ss2022 links then fail latency / URLTest, which makes them look unsupported by Mihomo even though SublinkPro already broke them before adapter creation.

I reproduced the failures on the latest unpatched main, then applied this patch on top of the same base and re-ran the checks. After the patch, the previously failing ss2022 samples passed URLTest successfully.

[ZeroDeng01]

Rebased onto the latest main and revalidated there before updating this PR.

This PR documents two user-visible failures with one shared root cause:

1. Valid plain SIP002 links in the form ss://cipher:password@host:port are decoded as if the userinfo were still base64.
2. The same affected ss2022 links then fail latency / URLTest, which makes them look unsupported by Mihomo even though SublinkPro already broke them before adapter creation.

I reproduced the failures on the latest unpatched main, then applied this patch on top of the same base and re-ran the checks. After the patch, the previously failing ss2022 samples passed URLTest successfully.

THX PR~

protocol/ss的测试内容放到ss_test而不是新建一个独立的新文件!