pex: avert a data race on map access in the reactor (#7614)

There was a path on which computing the next delivery time did not hold the
lock, defying the admonition on its comment.

internal/p2p/pex/reactor.go

@@ -158,10 +158,13 @@ func (r *Reactor) OnStop() {}
 func (r *Reactor) processPexCh(ctx context.Context) {
 	timer := time.NewTimer(0)
 	defer timer.Stop()
+
+	r.mtx.Lock()
 	var (
 		duration = r.calculateNextRequestTime()
 		err      error
 	)
+	r.mtx.Unlock()
 
 	incoming := make(chan *p2p.Envelope)
 	go func() {
@@ -377,7 +380,8 @@ func (r *Reactor) sendRequestForPeers(ctx context.Context) (time.Duration, error
 // as possible. As the node becomes more familiar with the network the ratio of
 // new nodes will plummet to a very small number, meaning the interval expands
 // to its upper bound.
-// CONTRACT: Must use a write lock as nextRequestTime is updated
+//
+// CONTRACT: The caller must hold r.mtx exclusively when calling this method.
 func (r *Reactor) calculateNextRequestTime() time.Duration {
 	// check if the peer store is full. If so then there is no need
 	// to send peer requests too often