perf(handshake): reuse the parsed X25519 private key

[JkLondon]

Config.PrivateKey is now *ecdh.PrivateKey, parsed once by the caller. This avoids deriving the same static public key on every authentication attempt.

Auth DH: 58.08 → 29.13 µs, 7 → 3 allocs/op (Go 1.27.0, darwin/arm64, Apple M3 Max; 10 runs). Microbenchmark only.

Checked locally: race detector, amd64 correctness and FIPS enforcement.

[RPRX]

Rebase，@yuhan6665 你看看

[RPRX]

需要再次 rebase，且我不确定这么搞是不是并发安全的，如果是的话就直接改接口吧别加锁了，test 文件删掉

顺便试试能不能 linkname #37 (comment) ，都放这个 PR 里吧

[yuhan6665]

需要再次 rebase，且我不确定这么搞是不是并发安全的，如果是的话就直接改接口吧别加锁了，test 文件删掉

顺便试试能不能 linkname #37 (comment) ，都放这个 PR 里吧

跟原版比似乎少了一个copy 不知道会不会有问题？
https://cs.opensource.google/go/x/crypto/+/master:curve25519/curve25519.go;l=91

[RPRX]

依稀记得不太并发安全，不然一开始就会这样写了，查一下吧，再让 AI 看看深层代码确认下，AI 最适合干这种事

[Fangliding]

个人感觉无所谓 在非瓶颈的路径上加缓存快点是快点但是终归是反模式 也就让握手快了 0.029 ms

[JkLondon]

Thanks for the discussion) Sadly, I don't know Chinese but as I understand from the translation :

1. According to the Go 1.27 X25519 implementation ECDH only reads and allocates a separate result for each call, so it's concurrently safe, I've done several tests, including race ones, all was ok.
2. talking about perf point @Fangliding mentioned: I'm maintaining pretty large xray server when I pprof it I saw that X25519 accounted for 8.00% of process CPU, the repeated derivation alone accounted for 1.99%. So, from my side it would not be THAT significant increase of CPU perf but anyway worth trying.
3. As @RPRX asked, I have deleted tests, and changed Config.PrivateKey to *ecdh.PrivateKey.