Fix set(key, value, Expiration, SetOption) ignoring KEEPTTL and unix-timestamp expirations - #7316

Closes #7315

RedissonConnection.set(byte[], byte[], Expiration, SetOption) never checked expiration.isKeepTtl() or expiration.isUnixTimestamp(), so both fell through to the relative-time branch.

• Expiration.keepTtl() sent its reserved negative sentinel to Redis as a literal PX value, which Redis rejects with ERR invalid expire time in 'set' command.
• Expiration.unixTimestamp(...) sent its absolute epoch-millis value as a PX delay instead of a PXAT deadline. This does not throw, so it silently produced a TTL decades in the future instead of the intended expiry time.

Scope

Expiration.isKeepTtl()/isUnixTimestamp() were added to Spring Data Redis incrementally, so the fix isn't uniform across every module:

I compiled all 16 potentially affected modules individually (mvn -DskipTests compile, not a reactor-wide build) to confirm each module only gets the branch its Expiration version actually supports.

Changes

• RedissonConnection.set(byte[], byte[], Expiration, SetOption): added the missing isKeepTtl() branch (mirroring the already-correct sibling setGet(byte[], byte[], Expiration, SetOption)) and, where supported, the missing isUnixTimestamp() branch (mirroring the already-merged getEx(byte[], Expiration) fix: always sends PXAT with the millisecond value, no separate seconds/EXAT branch, matching that method's style).
• Added/extended a regression test in six modules spanning the full supported version range (20 unaffected, 24/25 KEEPTTL-only, 26/30/40/41 both) covering the matrix of every Expiration kind times every SetOption, checking TTL correctness for the unixTimestamp cases rather than only checking for an exception. Added two more focused tests confirming the unixTimestamp fix produces the right TTL both when the Expiration was built with a MILLISECONDS value and with a SECONDS value.

Testing

Ran the full matrix against a real Redis instance across modules spanning the supported version range:

Module 20 (Spring Data Redis 2.0.14, unaffected): Tests run: 6, Failures: 0, Errors: 0 (unchanged)
Module 24 (Spring Data Redis 2.4.15, KEEPTTL only): Tests run: 13, Failures: 0, Errors: 0
Module 25 (Spring Data Redis 2.5.12, KEEPTTL only): Tests run: 13, Failures: 0, Errors: 0
Module 26 (Spring Data Redis 2.6.10, both): Tests run: 16, Failures: 0, Errors: 0
Module 30 (Spring Data Redis 3.0.12, both): Tests run: 19, Failures: 0, Errors: 0
Module 40 (Spring Data Redis 4.0.5, both): Tests run: 32, Failures: 0, Errors: 0
Module 41 (Spring Data Redis 4.1.0, both): Tests run: 32, Failures: 0, Errors: 0

Before this fix, the matrix failed on the keepTtl row under all three SetOption values with the exact error from the issue (ERR invalid expire time in 'set' command, PX -2000), and on the unixTimestamp row (in modules where that Expiration kind exists) under all three SetOption values, reporting a ~56-year TTL instead of the intended ~2-minute one. All other combinations already passed and are unaffected by this change.

Also reproduced and re-verified directly against redis-cli (bypassing redisson entirely) to confirm the malformed KEEPTTL command and the fix's KEEPTTL/KEEPTTL NX/KEEPTTL XX/PXAT ... NX/PXAT ... XX syntax are all exactly what Redis expects.