Fix ResourceWatcher Data Race and Redis Connection Leaks

[chungeun-choi]

Description

This PR severely boosts the operator’s concurrent throughput and fixes internal blocking bottlenecks when orchestrating multiple RedisReplication resources efficiently.

The detailed changes include:

1. Fix ResourceWatcher Thread-Safety: Replaced the value receiver with a pointer receiver (w *ResourceWatcher) and implemented sync.RWMutex to protect the watched map against Data Races when MAX_CONCURRENT_RECONCILES > 1.
2. Fix TCP Connection Leaks: Restructured GetRedisNodesByRole to wrap the configureRedisReplicationClient and defer redisClient.Close() execution in an anonymous function. This ensures stale connections close immediately per iteration rather than hogging connections inside the for loop until return.
3. Optimize Redundant Topologies: Re-factored the redisreplication_controller.go to merge reconcileRedis and reconcileStatus into a single reconcileRedisAndStatus function yielding a ~50% reduction in concurrent TCP handshakes per reconcile step.

Fixes #ISSUE

Type of change

• Bug fix (non-breaking change which fixes an issue)

Checklist

• Tests have been added/modified and all tests pass.
• Functionality/bugs have been confirmed to be unchanged or fixed.
• I have performed a self-review of my own code.
• Documentation has been updated or added where necessary.

Additional Context

In a local constrained environment (Docker Desktop) orchestrating 30 RedisReplication clusters simultaneously:

• Before fixing: Throughput severely choked around ~3.75 successfully labeled masters per minute due to connection exhaustion and constant TCP timeouts blocking workers.
• After patching: Throughput rocketed to ~13.12 masters per minute (about ~3.5x improvement) dynamically consuming all the local constraints without causing go routine leaks or panic logs.