Randomize cluster startup node order during topology refresh

[petyaslavova]

Randomizes the startup node iteration order during cluster topology initialization for both sync and async clients. This prevents many clients from consistently querying the same first startup node when reinitializing cluster state.

The implementation copies startup_nodes to a list, shuffles it when multiple nodes are available, and then proceeds with the existing initialization flow. Sync behavior still includes any additional startup nodes after the shuffled startup node list, preserving the existing MOVED refresh path behavior.

Adds sync and async cluster tests that use the real cluster fixture and mock only random.shuffle to make the order deterministic. The tests verify that initialization queries the node that becomes first after shuffling.

Fixes #4049

---

Note

Medium Risk
Changes cluster topology refresh ordering and retry initialization behavior (sync + asyncio), which can affect how clients recover from node failures and MOVED/connection errors. Test changes reduce timing flakiness but don’t alter lock semantics.

Overview
Cluster topology refresh is now randomized. Both sync and asyncio NodesManager.initialize() copy startup_nodes to a list and random.shuffle() it (when multiple nodes exist) so clients don’t consistently query the same first node during reinitialization.

Failed nodes are deprioritized on refresh. Connection/timeout errors now annotate the exception with last_failed_node_name, and subsequent initialize() calls pass this through so the failed node is tried after other startup and additional startup nodes.

Tests updated/added. New sync/async cluster tests assert shuffling is applied (via deterministic random.shuffle mocking), and lock blocking-timeout tests now use patched fake time modules to avoid real-time assertions and flakiness.

^{Reviewed by Cursor Bugbot for commit 883effe. Bugbot is set up for automated code reviews on this repo. Configure here.}

[jit-ci]

🛡️ Jit Security Scan Results

✅ No security findings were detected in this PR

---

^{Security scan by Jit}

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 9006304. Configure here.}

[vladvildanov]

So async initialisation never passes additional_startup_nodes_info?

[petyaslavova]

@vladvildanov Currently, no - it was added for the maintenance notifications handling in sync client. I'm adding this now, so that later, when the maintenance notifications are added to the sync client we will have the same order of the arguments.