Shard is not reachable after toogle peer TLS

IF we have a shard integrated with a config server , with peer TLS enabled on both applications. Then remove the TLS relation in the shard and add it again, the cluster is not active

## Steps to reproduce

1. Deploy a config-server
2. Deploy a shard
3. Deploy self-signed-certificates
4. Integrate config-server and shard
5. Integrate config-server and self-signed-certificates on peer-certificates interface
6. Integrate shard and self-signed-certificates on peer-certificates interface
7. Remove relation between shard and self-signed-certificates on peer-certificates interface
8. Wait for it to idle
9. Integrate shard and self-signed-certificates on peer-certificates interface

** CONFIG SERVER **

```
config-server2/0* blocked idle 4 10.26.146.149 27017-27018/tcp Shards: shard2 is unreachable.
```

**SHARD**
```
shard2/0* waiting idle 5 10.26.146.101 27017/tcp Waiting for primary re-election.... Run `status
-detail`: 0 action required; 1 additional statuses.
```

## Expected behavior
Both the config server and shard goes to active state

## Actual behavior

Config server is blocked and shard is in waiting status

## Versions

Operating system:

Juju CLI: 3.6.20

Juju agent:

Charm revision: mongodb operator VM 8/edge - revision 335

LXD:

## Log output

Juju debug log:

## Additional context

Reproduce the deployment with config-server, shard, and self-signed-certificates, then remove and restore the shard's peer-certificates relation. Start with the shard and config-server status transitions, especially the waiting state during primary re-election. Done means both applications return to active after the relation is restored and the shard is reachable again.

Written by the indexing model from the issue text.