… in advance

When writing test case for valkey-io#2431, i found that the corresponding test
case occasionally triggered this debug assert:
```
Node ef54ff291855537b7f4f61c815955310e55bc9e2 () is no longer primary of shard ab1e16d7e11cbb0d81acf0bab4191d84e19df092; removed all 5462 slot(s) it used to own
Node ef54ff291855537b7f4f61c815955310e55bc9e2 () is now part of shard aad3ac4bf806c2bd5441ed5c421893be20f02797
Node ef54ff291855537b7f4f61c815955310e55bc9e2 () is now a replica of node a1d09af28a10d58deb43ccc8bddd8c8d095a5af5 () in shard aad3ac4bf806c2bd5441ed5c421893be20f02797

=== VALKEY BUG REPORT START: Cut & paste starting from here ===
=== ASSERTION FAILED ===
==> cluster_legacy.c:7004 'primary->replicaof == ((void*)0)' is not true

------ STACK TRACE ------

Backtrace:
0   valkey-server                       0x000000010507ac70 clusterUpdateSlotsConfigWith + 0
1   valkey-server                       0x0000000105077564 clusterReadHandler + 6180
2   valkey-server                       0x00000001050f3b0c connSocketEventHandler + 180
3   valkey-server                       0x0000000104fb7f9c aeProcessEvents + 372
4   valkey-server                       0x0000000104fe2d30 main + 27676
5   dyld                                0x0000000199177154 start + 2476
```

And we can see from the cluster nodes output, there are indeed a replication loop:
```
sender: ef54ff291855537b7f4f61c815955310e55bc9e2
sender_claimed_primary: a1d09af28a10d58deb43ccc8bddd8c8d095a5af5

ef54ff291855537b7f4f61c815955310e55bc9e2 shard-id=ab1e16d7e11cbb0d81acf0bab4191d84e19df092 slave a1d09af28a10d58deb43ccc8bddd8c8d095a5af5
a1d09af28a10d58deb43ccc8bddd8c8d095a5af5 shard-id=aad3ac4bf806c2bd5441ed5c421893be20f02797 slave ef54ff291855537b7f4f61c815955310e55bc9e2
```

The sender and sender_claimed_primary are not in the same shard, and
sender_claimed_primary is a replica in myself view, if we don't update
sender_claimed_primary role, in the next `sender->replicaof = sender_claimed_primary`,
we will create the replication loop.

Signed-off-by: Binbin <binloveplay1314@qq.com>

In valkey-io#2431 we changed the assert to a if condition, and the test
cause some trouble, now we just remove the assert (if condition)
and disable the test for now due to valkey-io#2441.

Signed-off-by: Binbin <binloveplay1314@qq.com>

In #2431 we changed the assert to a if condition, and the test cause
some trouble, now we just remove the assert (if condition) and disable
the test for now due to #2441.

Signed-off-by: Binbin <binloveplay1314@qq.com>

…alkey-io#2431)

The assert was added in valkey-io#2301 and we found that there are some situations
would trigger assert and crash the server.

The reason we added the assert is because, in the code:
1. sender_claimed_primary and sender are in the same shard
2. and sender is the old primary, sender_claimed_primary is the old replica
3. and now sender become a replica, sender_claimed_primary become a primary

That means a failover happend in the shard, and sender should be the primary
of sender_claimed_primary. But obviously this assumption may be wrong, we rely
on shard_id to determine whether it is in a same shard, and assume that a shard
can only have one primary.

But this is wrong, from valkey-io#2279 we can know there will be a case that we can
create two primaries in the same shard due to the untimely update of shard_id.
So we can create a test that trigger the assert in this way:
1. pre condition: two primaries in the same shard, one has slots and one is empty.
2. replica doing a cluster failover
3. the empty primary doing a cluster replicate with the replica (new primary)

We change the assert to an if condition to fix it.

Closes valkey-io#2423.

Note that the test written here also exposes the issue in valkey-io#2441, so these two
may need to be addressed together.

Signed-off-by: Binbin <binloveplay1314@qq.com>

In valkey-io#2431 we changed the assert to a if condition, and the test cause
some trouble, now we just remove the assert (if condition) and disable
the test for now due to valkey-io#2441.

Signed-off-by: Binbin <binloveplay1314@qq.com>

In valkey-io#2431 we changed the assert to a if condition, and the test cause
some trouble, now we just remove the assert (if condition) and disable
the test for now due to valkey-io#2441.

Signed-off-by: Binbin <binloveplay1314@qq.com>

In #2431 we changed the assert to a if condition, and the test cause
some trouble, now we just remove the assert (if condition) and disable
the test for now due to #2441.

Signed-off-by: Binbin <binloveplay1314@qq.com>

…alkey-io#2431)

The assert was added in valkey-io#2301 and we found that there are some situations
would trigger assert and crash the server.

The reason we added the assert is because, in the code:
1. sender_claimed_primary and sender are in the same shard
2. and sender is the old primary, sender_claimed_primary is the old replica
3. and now sender become a replica, sender_claimed_primary become a primary

That means a failover happend in the shard, and sender should be the primary
of sender_claimed_primary. But obviously this assumption may be wrong, we rely
on shard_id to determine whether it is in a same shard, and assume that a shard
can only have one primary.

But this is wrong, from valkey-io#2279 we can know there will be a case that we can
create two primaries in the same shard due to the untimely update of shard_id.
So we can create a test that trigger the assert in this way:
1. pre condition: two primaries in the same shard, one has slots and one is empty.
2. replica doing a cluster failover
3. the empty primary doing a cluster replicate with the replica (new primary)

We change the assert to an if condition to fix it.

Closes valkey-io#2423.

Note that the test written here also exposes the issue in valkey-io#2441, so these two
may need to be addressed together.

Signed-off-by: Binbin <binloveplay1314@qq.com>
Signed-off-by: Harkrishn Patro <harkrisp@amazon.com>

In valkey-io#2431 we changed the assert to a if condition, and the test cause
some trouble, now we just remove the assert (if condition) and disable
the test for now due to valkey-io#2441.

Signed-off-by: Binbin <binloveplay1314@qq.com>
Signed-off-by: Harkrishn Patro <harkrisp@amazon.com>