RedisLockRegistry UNLINK command (optimization)

[FranPregernik]

In what version(s) of Spring Integration are you seeing this issue?

5.4.1

Describe the bug

The RedisLockRegistry is creating RedisLock instances that test the Redis backend if it supports the UNLINK command.
If it does not, a local variable unlinkAvailable is set to false and the error is logged as a warning.
This causes the RedisLock instance to use the old DELETE command.

There are two issues with this.

First one is that each new RedisLock instance will do the above logic over and over again (for every new instance once). Since Lock instances are mostly short lived that is a lot of UNLINK command testing towards the same Redis backend. We can assume the Redis version does not change during the runtime of the application.

The other, smaller, issue is that the log warning message in its current form can't be silenced/minimized and always outputs an Exception stack trace which adds a great deal of noise to the log.

To Reproduce

Point the RedisLockRegistry to an older version of Redis that does not support the UNLINK command.

Expected behavior

This detection of UNLINK support should be moved to the RedisLockRegistry and the unlinkAvailable command should be passed as a constructor param to RedisLock (base idea by @artembilan #3041 (comment))

The log warning message should be logged without the stack trace and if the stack trace is important it should be guarded under a log.isDebugEnabled or similar.

Sample

Sorry... might be too basic of an example to warrant a sample. It would have to be some kind of docker compose example to include an older version of Redis... or TestContainers...