Allow transparent rolling restarts of a dotCMS cluster to logged-in, backend users

[sfreudenthaler]

Parent Issue

Epic: support evergreen deployments in dotCMS Cloud #67

User Story

As a dotCMS user, I want upgrades to happen without downtime, so that I can greatly reduce the effort and disruption of getting a new version

As a cloud engineer, I want to be pod updates/changes to be transparent to users, so that I can start doing deployments outside of maintenance windows.

Acceptance Criteria

1. Active user sessions should persist even when all the pods in the stateful set have been replaced
2. Unsaved/Unpublished user changes should not get lost when we replace pods in the stateful set
3. Enabling ALB sticky sessions is no longer necessary (but may still be beneficial)

Proposed Objective

Reliability

Proposed Priority

Priority 2 - Important

External Links... Slack Conversations, Support Tickets, Figma Designs, etc.

• short intro to stateful set upgrade strategies
• K8s documentation: StatefulSet pod upgrade strategies

Assumptions & Initiation Needs

1. Assumption: we're not going to become a truly stateless application anytime soon
2. Needs: supporting Redis session storage in Cloud deployments

Quality Assurance Notes & Workarounds

No response

Sub-Tasks & Estimates

No response

### Related
- [ ] https://github.com/dotCMS/private-issues/issues/82
- [ ] https://github.com/dotCMS/private-issues/issues/73
- [ ] https://github.com/dotCMS/core/issues/29355
- [ ] https://github.com/dotCMS/private-issues/issues/81
- [ ] https://github.com/dotCMS/core/issues/25570
- [ ] [SPIKE] - What happens to key flows when multi-server cluster rolls containers under load
- [ ] https://github.com/dotCMS/core/issues/30374
- [ ] https://github.com/dotCMS/core/issues/30413