fix(gossipsub): Fix underflow when shuffling peers after prunning.

I noticed two issues during testing.

1.  We allow our mesh to grow greater than `mesh_n_high`, intentionally
2.  There is a potential underflow in the heartbeat that can cause a panic

For the first 1. This looks like its intentional but I can't recall why we would have added it. I think its counter-intuitive to allow our mesh to grow larger than the specified parameter. I suspect we added it to prevent our mesh from being filled with inbound peers and potentially being eclipsed. I suspect the best approach here is to remove inbound peers in the mesh maintenance rather than exceeding the mesh_n_high configuration.

For 2. There is an underflow which this PR prevents. It can be triggered for low mesh_n_high values, i.e 0. This shouldn't be a concern for regular users, but we shouldn't have code that can panic based on user configuration.

Pull-Request: #6183.

Author: AgeManning

protocols/gossipsub/CHANGELOG.md

@@ -1,4 +1,7 @@
 ## 0.50.0
+- Fix underflow when shuffling peers after prunning.
+  See [PR 6183](https://github.com/libp2p/rust-libp2p/pull/6183)
+
 - Remove peer penalty for duplicate messages.
   See [PR 6112](https://github.com/libp2p/rust-libp2p/pull/6112)
 

protocols/gossipsub/src/behaviour.rs

@@ -2228,7 +2228,9 @@ where
                     score_p1.partial_cmp(&score_p2).unwrap_or(Ordering::Equal)
                 });
                 // shuffle everything except the last retain_scores many peers (the best ones)
-                shuffled[..peers.len() - self.config.retain_scores()].shuffle(&mut rng);
+                if peers.len() > self.config.retain_scores() {
+                    shuffled[..peers.len() - self.config.retain_scores()].shuffle(&mut rng);
+                }
 
                 // count total number of outbound peers
                 let mut outbound = shuffled