🚀 Optimize JSON-RPC Deserialization Performance with Type Switch Pattern

[qiangmzsx]

Description:
This PR introduces a significant performance improvement to JSON-RPC message deserialization by replacing the original sequential type-checking approach with a more efficient type switch pattern. The new implementation reduces deserialization overhead through:

1. Single JSON Parsing: Eliminates redundant JSON unmarshaling attempts
   ​2. Structured Common Type: Uses JSONRPCCommon as an intermediate type for type discrimination
   ​3. Optimized Dispatch: Implements a switch-case pattern for message type resolution

Key Improvements:

// Before: 4x JSON.Unmarshal attempts per message
func deserializeMessage(line string) (*transport.BaseJsonRpcMessage, error) {
    var request... // 4 separate unmarshal attempts
}

// After: Single unmarshal + type switch
func deserializeMessageV2(line string) (*transport.BaseJsonRpcMessage, error) {
    var tmp transport.JSONRPCCommon
    if err := json.Unmarshal([]byte(line), &tmp); err != nil { // Single parse
        return nil, fmt.Errorf("failed to parse JSON: %w", err)
    }
    
    switch { // Efficient type discrimination
    case tmp.Method != "" && tmp.Id != nil: // Request
    case tmp.Method != "" && tmp.Id == nil: // Notification
    case tmp.Result != nil && tmp.Id != nil: // Response
    case tmp.Error != nil && tmp.Id != nil:  // Error response
    }
}

Performance Benchmark:
goos: darwin
goarch: arm64
pkg: github.com/metoro-io/mcp-golang/transport/stdio/internal/stdio
cpu: Apple M3 Pro
BenchmarkDeserializeMessage-11 132722 9049 ns/op
BenchmarkDeserializeMessage_v2-11 473245 2559 ns/op
PASS
ok github.com/metoro-io/mcp-golang/transport/stdio/internal/stdio 4.024s

[Copilot]

Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.

Comments suppressed due to low confidence (1)

transport/stdio/internal/stdio/stdio.go:166

• [nitpick] Consider replacing comments in Chinese with English to ensure consistency and clarity for all team members.

// 请求消息（包含 Method 和 Id）

[Copilot]

In non-request branches (e.g., notifications, response, and error responses), the response channel stored in t.responseMap is never deleted, potentially causing a resource leak. Consider cleaning up the channel (e.g., deleting the channel from t.responseMap) before returning.