Clean Redis principal index during expiration cleanup

[yeomin4242]

When Redis expiration events are unavailable, the expires key may be gone while the session hash remains available in the grace period. Clean the principal index during the existing expiration cleanup flow when that session is already expired.

Summary

• clean stale Redis principal index entries from the existing Redis expiration cleanup flow
• handle the case where sessions:expires:<sessionId> is already gone while the session hash is still available and expired
• add a Redis static master/replica integration test that reproduces missing expiration events with RedisStaticMasterReplicaConfiguration

Addresses gh-1715.

Notes

This keeps the cleanup in RedisIndexedSessionRepository's expiration cleanup path. It does not change findByIndexNameAndIndexValue, so index lookups do not gain cleanup side effects.

The cleanup only removes the principal index entry when the session hash can still be loaded and the session is already expired. If the session hash is no longer available, this change leaves the index entry untouched.

This PR does not change SortedSetRedisSessionExpirationStore behavior.

[jzheaux]

Hi, @yeomin4242, thanks for the PR. I'm not yet convinced that what's needed is for expiration store to manually intervene. I've posted a theory and some code to #1715 and we'll see what comes of it. For now, I'm blocking this PR so it doesn't accidentally get merged while that investigation continues.

[yeomin4242]

Thanks for investigating this.

I tested the two-connection-factory configuration described in #1715 locally: RedisStaticMasterReplicaConfiguration with REPLICA_PREFERRED for RedisIndexedSessionRepository operations, and a RedisStandaloneConfiguration pointing to the master for RedisMessageListenerContainer. I also enabled Ex keyspace notifications and registered the standard Spring Session subscriptions.

With this setup, TTL expiration removed the PRINCIPAL_NAME_INDEX_NAME membership through the existing message-listener path. The test does not invoke cleanUpExpiredSessions(), so the expiration-store fallback proposed in this PR is not involved.

This suggests that separating the Pub/Sub connection addresses the stale-index scenario I reproduced. I agree that having the expiration store perform this cleanup is likely not the right direction.