GH-3716: Fix wait for init redisMessageListenerContainer

[Meteorkor]

Fix wait for init redisMessageListenerContainer

Container A, Request to LockA -> redisMessageListenerContainer is starting (not done)
Container B, Request to LockB, obtain Lock
Container A, Request to LockB -> subscribeUnlock(wait unlock msg), but redisMessageListenerContainer is not done
Container B, Request to LockB, unlock LockB and publish unlockMsg(LockB), but Container A not received

#3716 (comment)

to-be
If the redisMessageListenerContainer is starting, Waiting for redisMessageListenerContainer to complete without doing subscribeUnlock()

[artembilan]

I think just one our isRunningRedisMessageListenerContainer is enough.
The problem is really that RedisMessageListenerContainer sets running = true; in the beginning of start().
Better to have it in the end, when subscription is ready.
But still we need that synchronized (RedisLockRegistry.this.redisMessageListenerContainer) anyway to block any concurrent calls for the start().

WDYT?

[Meteorkor]

The problem is really that RedisMessageListenerContainer sets running = true; in the beginning of start().

I agree with what you said.
However, it was thought that it would be difficult to change that part in spring-integration, so I modified the code to handle it.

The reason to check both is because there is a code that sets running = false;
(isRunningRedisMessageListenerContainer and redisMessageListenerContainer.isRunning())
when an error occurs in redisMessageListenerContainer.start(), but will be not threw Exception.
(https://github.com/spring-projects/spring-data-redis/blob/main/src/main/java/org/springframework/data/redis/listener/RedisMessageListenerContainer.java#L222)

There is almost no failure, but if it fails, it looks like we will have to run start() again, so I'm checking both.

[artembilan]

... and cherry-picked to 5.5.x.

@Meteorkor ,

thank you as usual for great and thoughtful work!