fix: improve node selection in sticky session

[zghong]

Description

Fixed the bug where chproxy always selects nodes only from a small subset of all nodes, for any random session_id.

Additionally, resolved performance bottlenecks caused by inefficient usage hash(sessionId) within loops.

Closes #574

Pull request type

Please check the type of change your PR introduces:

• Bugfix
• Feature
• Code style update (formatting, renaming)
• Refactoring (no functional changes, no api changes)
• Build related changes
• Documentation content changes
• Other (please describe):

Checklist

• Linter passes correctly
• Add tests which fail without the change (if possible)
• All tests passing
• Extended the README / documentation, if necessary

Does this introduce a breaking change?

• Yes
• No

Further comments

By design, sticky sessions should consistently route all requests with the same session_id to the exact same node, regardless of whether the node is active or not. However, the current implementation fails to maintain this consistency when the selected node's active status changes during this period. Resolving this issue presents challenges, especially in chproxy topologies with 2 or more replicas, which may require introducing distributed storage solutions like Redis. I have added TODO in the code and will open another issue about this.

• Example 1: A sticky session initially routes requests to node 127.0.1.1 based on its session_id. If 127.0.1.1 later becomes inactive, subsequent requests with the same session_id are incorrectly rerouted to another active node (e.g., 127.0.2.2) instead of remaining directed to 127.0.1.1.
• Example 2: A sticky session should route to node 127.0.1.1 but initially selects 127.0.2.2 because 127.0.1.1 is inactive. When 127.0.1.1 later becomes active, subsequent requests with the same session_id are incorrectly switched to 127.0.1.1, breaking session stickiness.