Infinispan Protostream Marshaller

[pruivo]

Closes #29394

I'm gathering earlier feedback and sharing how it will end up.
Pending tasks are:

• Compute the final Protostream IDs. With Protostream IDs, it generates smaller payloads since it sends the IDs (Goole Protobuf varInt) instead of the message name.
• Refactor events and predicates. I'm taking the opportunity to remove unused fields and duplicated code.
• Migration from JBoss Marshalling to Infinispan Protostream
• Re-add JBoss Marshalling to allow migration of sessions
• Add clearing of caches on migration to KC25 - all entries in the caches will be gone
• Documentation for the release notes

Out of scope: Existing entries in the session cache will be migrated in PR #29377

Migration

The migration path is under discussion and has the following assumptions:

• Only user and client sessions will be migrated. All other data stored in distributed/replicated caches will be lost.
• Embedded cache needs to have persistence configured. If only in-memory storage is configured, we assume that losing sessions during Keycloak major version upgrade is acceptable and expected.

The most appealing solution is to start a separate, non-clustered Infinispan CacheManager with JBoss-Marshalling configured (the CacheManager is limited to a single marshalled). This CacheManager will be used to read the old session data. Then, we have the following 2 scenarios

• Persistent User Sessions feature is enabled. Using the JBoss-Marshalling CacheManager to read the sessions and store them in the database. The cache is clear at the end.
• Without Persistent User Session feature, it reads the sessions from the JBoss-Marshalling CacheManager and writes them in the Protostream enabled CacheManager.

[ryanemerson]

@pruivo Do you plan to add the proto compatibility check capabilities as part of this PR or should we create an issue to add that in a subsequent PR? I would be happy with the latter given how large the current PR is.

[ryanemerson]

s/ResourceRemovedEvent/ResourceEvent

[ryanemerson]

From a schema evolution POV I think it would make more sense to keep the three event types as distinct messages. That way the schema is more representative of the three logic types and we can easily add new event specific fields to the messages if required.

Obviously there's a lot of duplicated code between these classes, but we could still leverage an abstract class to reduce this.

[pruivo]

I was afraid someone would say that 🤣
Sure, I can revert my changes.

[stianst]

Please do not merge until we decide if this should be included in Keycloak 25, or shortly after the release