For CMS Preview and PageComposer use a dedicated CmsSessionContext object to share state with the HST web application(s)

The current integration between the CMS and HST (site) application(s) uses a 'SSO' handshake between CMS and HST through which the Repository Credentials are serialized (encrypted) so that the HST can render preview content or provide data through REST using the credentials of the CMS user.
However, this solution doesn't scale well when additional CMS session state is needed.

To solve this limitation a new shared CmsContextService is introduced which provide access to a new CmsSessionContext for which only their unique identifiers need to be communicated between the CMS and HST application(s).
The HST application can use these identifiers to access the CmsSessionContext object from the CMS application directly via the shared CmsContextService.

A CmsSessionContext object will be bound to the current web application HttpSession and automatically invalidate when removed, the session itself is invalidated or passivated.
For CMS Preview rendering in the HST a separate CmsSessionContext object will be created and bound to the HST HttpSession, which is attached to the CmsSessionContext object within the CMS HttpSession.
The 'handshake' between the CMS and HST webapplication only needs to be done once, until either session (or CmsSessionObject) invalidates.
HST attached CmsSessionContext objects will automatically invalidate when the CmsSessionObject in the CMS HttpSession is invalidated.

Note that this new solution explicitly expect and requires that the CMS and HST webapplication(s) as accessed by the browser are served by the same application container instance (e.g. Tomcat).
For clustered instances this means that the loadbalancer must map requests to these applications to the same container instance.

It also means that the hippo.cluster.sso.key system property no longer is effective (there is no encryption key used anymore anyhow).

While that 'trick' could help elevate some ChannelManager problems in case of bad behaving or wrongly configured (incorrect cookie paths for cms and site) application instance(s) and loadbalancer, technically and functionally that 'solution' wasn't proper nor desirable to begin with.
It allowed for combining the output and interaction from a CMS and HST application(s) from different container instances across a cluster.
Such container instances, with each their own Hippo Repository, can (will be) temporarily skewed until their backend state was synchronized again, the end-user experience therefore also could be skewed.

With a proper setup of the loadbalancer, using cookie prefix rewriting per appication instance for example, and using the right cookie paths for cms and site(s), skewed access to the cms and hst application(s) from a client browser should typically not occur.
And in case they do (like during intermittent instance failover), the handshake between the CMS and HST applications will detect this and autmatically try to repair this, or with a repeated skewed handhake eventually logout the user (forcibly).