Add backup/restore CRD design document

Design for CRD-based backup/restore automation in openstack-operator.
Eliminates need for external client systems.

Key Decisions:
1. Operator location: openstack-operator (avoids import loops)
2. Playbook versioning: Embedded in operator, thoroughly documented
3. Backup retention: Tiered strategy (hourly local + daily S3)
   - OADP TTL handles cleanup automatically
   - Snapshot history for free via CSI snapshots
4. Partial restore: Not supported (consistency critical)
5. Backup validation: Basic checks + optional Tempest post-restore
6. Controller design: Generic controller, logic in playbooks
   - Maximum flexibility via playbook override
   - Emergency fixes without operator release
7. OADP strategy: One atomic backup for all PVCs
   - Consistent point-in-time snapshot
   - Selective restore supported (inspect before full restore)
8. Metadata: Use OADP backup list + archive contents
   - No dedicated metadata PVC needed

Proposed CRDs:
- OpenStackControlPlaneBackup/Restore
- OpenStackDataPlaneBackup/Restore

Implementation:
- Controllers in openstack-operator
- Ansible-runner execution (like EDPM)
- Playbook override via Secret (like EDPM)
- CSI snapshots + S3 data movement (OADP)
- Status tracking for multi-stage restore

Recommended tiered backup pattern:
- Hourly: Local snapshots (24h retention, fast recovery)
- Daily: S3 backups (30d retention, disaster recovery)

Disaster recovery workflow documented for fresh cluster restore.

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>

Author: stuggi