Reduce lock granularity

[Shawyeok]

implements #2191

[yangbodong22011]

@Shawyeok thanks, I have a concern about "Reduce lock granularity" will bring more renewClusterSlots.

In your code, before discoverClusterSlots->w.lock();, user requests can also call getConnectionFromSlot, but the cluster route is old (renewSlotCache not yet complete), so some requests will get JedisRedirectionException and call renewSlotCache once again.

This is inconsistent with the original Jedis behavior. Do we have a way to block those requests that will return JedisRedirectionException again and let others pass?

[Shawyeok]

In your code, before discoverClusterSlots->w.lock();, user requests can also call getConnectionFromSlot, but the cluster route is old (renewSlotCache not yet complete), so some requests will get JedisRedirectionException and call renewSlotCache once again.

@yangbodong22011 In this scenario, rediscoverLock.tryLock() will returns false immediately.

[yangbodong22011]

In this scenario, rediscoverLock.tryLock() will returns false immediately.

oh, nice, so the behavior can be the same as before, and the lock time of redis.clients.jedis.JedisClusterInfoCache#slots is reduced.

[yangbodong22011]

LGTM

[sazzad16]

LGTM the core changes.

[dengliming]

LGTM