Enable state transfer even if a remote cache is enabled

[ahus1]

This re-enables the state transfer even if the remote store is enabled.

There are some situations when listing user sessions for example in InfinispanUserSessionProvider where cache loaders are skipped, so all entries should be in the cache for this case. The state transfer ensures that this is the case when a node joins or leaves.

https://github.com/keycloak/keycloak/blob/c036980c3759b833d98030cf1299297a7ec97436/model/infinispan/src/main/java/org/keycloak/models/sessions/infinispan/InfinispanUserSessionProvider.java#L396-L397

[ahus1]

@pruivo - if you have the time, please comment on this PR. I see this as a step backwards in terms of performance, but it seems to me that it is the only way to produce correct results.

[pruivo]

@ahus1 the PR looks ok to me.

[pruivo]

@ahus1 Having second thought, the code in [1] needs to be fixed. It won't behave properly in the following scenarios

• if num-owners Keycloak servers crash, the sessions are lost from in-memory embedded Infinispan, and the iteration will miss those.
• Keycloak receives an XML configuration file and users may configure it to limit the number of sessions in memory (eviction). Once again, the iteration won't be correct and won't return all sessions.

[1] https://github.com/keycloak/keycloak/blob/c036980c3759b833d98030cf1299297a7ec97436/model/infinispan/src/main/java/org/keycloak/models/sessions/infinispan/InfinispanUserSessionProvider.java#L396-L397

[ahus1]

I think all of that was done for performance reasons to not touch the remote store. I wonder how much performance impact we could expect here when we allow accessing the remote store. I need to understand better how Infinispan behaves.

[ahus1]

As discussed on the call: Using the remote store here would always fetch all entries from the remote store, which would have quite a performance penalty. Deferring optimizations to when we move to a remove Infinispan (possibly with Ickle queries)