feat: add sentinel-free architecture with operator-managed failover (v1.7.0)

[usiegj00]

Summary

Add spec.sentinel.enabled field to allow operator-managed failover instead of Redis Sentinel, reducing pod overhead from 5 pods (2 Redis + 3 Sentinel) to 2 pods (Redis only).

This is the v1.7.0 release.

Changes

Core Implementation

• Add sentinel.enabled (default: true) and sentinel.failoverTimeout (default: 10s) API fields
• Add GetReplicationInfo() to Redis client for smart replica selection by replication offset
• Add operator-managed failover logic (checkAndHealOperatorManagedMode)
• Add EnsureNotPresentSentinelResources() for Sentinel resource cleanup
• Add PromoteBestReplica() for failover with replication offset-based selection
• Modify shutdown script to skip Sentinel failover when disabled

Documentation

• Update README with sentinel-free mode documentation
• Update version references to v1.7.0
• Add connection instructions for sentinel-free mode
• Update roadmap

Testing

• Add unit tests for new API methods
• Add E2E test job for sentinel-free mode:
  • Verifies NO Sentinel resources created
  • Verifies master election
  • Tests operator-managed failover
  • Verifies data survives failover

Failover behavior when sentinel.enabled=false

Condition	Action
0 masters	Elect best replica by replication offset (or oldest as fallback)
1 master	Check health, failover if unhealthy
Multiple masters	Error state requiring manual intervention

Example Usage

apiVersion: databases.spotahome.com/v1
kind: RedisFailover
metadata:
  name: my-redis
spec:
  redis:
    replicas: 2
  sentinel:
    enabled: false  # Operator manages failover
    failoverTimeout: "10s"

Test plan

• Unit tests pass (go test ./...)
• Code compiles (go build ./...)
• E2E: Sentinel resources NOT created when enabled: false
• E2E: Operator elects master on startup
• E2E: Operator fails over when master pod deleted
• E2E: Data survives failover

Closes #9