fix: restore WAL from replica source during designated primary promotion

During a replica cluster failover, the designated primary could incorrectly
attempt to restore WALs from its own object store instead of the replica
source, causing recovery to fail. This happened because the previous logic
relied on IsReplica() returning true, but that flag can already be false
while PostgreSQL is still in recovery and needs WALs from the source cluster.

Signed-off-by: Leonardo Cecchi <leonardo.cecchi@enterprisedb.com>

internal/cnpgi/common/wal.go

@@ -242,20 +242,13 @@ func (w WALServiceImplementation) Restore(
 	var serverName string
 	var objectStoreKey types.NamespacedName
 
-	var promotionToken string
-	if configuration.Cluster.Spec.ReplicaCluster != nil {
-		promotionToken = configuration.Cluster.Spec.ReplicaCluster.PromotionToken
-	}
-
 	switch {
-	case promotionToken != "" && configuration.Cluster.Status.LastPromotionToken != promotionToken:
+	case configuration.Cluster.Status.CurrentPrimary == w.InstanceName &&
-		// This is a replica cluster that is being promoted to a primary cluster
+		len(configuration.ReplicaSourceBarmanObjectName) > 0:
-		// Recover from the replica source object store
+		// restore_command is only called while PostgreSQL is in recovery, so if this
-		serverName = configuration.ReplicaSourceServerName
+		// instance is the current primary with a replica source configured, it must be
-		objectStoreKey = configuration.GetReplicaSourceBarmanObjectKey()
+		// a designated primary that hasn't completed promotion yet. This covers both
-
+		// switchover (promotion token) and failover (no promotion token) cases.
-	case configuration.Cluster.IsReplica() && configuration.Cluster.Status.CurrentPrimary == w.InstanceName:
-		// Designated primary on replica cluster, using replica source object store
 		serverName = configuration.ReplicaSourceServerName
 		objectStoreKey = configuration.GetReplicaSourceBarmanObjectKey()