Reverting a few lines from PR #2406

As discussed with @mitchellh and @phinze we don’t need to randomize in
order to get infinite ID’s. When we hit the highest possible number and
add `1` it will just wrap back to `0`, which is just fine with regards
to how Terraform works and uses these ID’s.

Tested this by setting the initial value of `m.nextId` to `4294967293`
where the maximum is `4294967295 `. So with some additional logging it
clearly showed it wrapped and continued without any issues.

rpc/mux_broker.go

@@ -3,9 +3,9 @@ package rpc
 import (
 	"encoding/binary"
 	"fmt"
-	"math/rand"
 	"net"
 	"sync"
+	"sync/atomic"
 	"time"
 
 	"github.com/hashicorp/yamux"
@@ -17,6 +17,7 @@ import (
 // or accept a connection from, and the broker handles the details of
 // holding these channels open while they're being negotiated.
 type muxBroker struct {
+	nextId  uint32
 	session *yamux.Session
 	streams map[uint32]*muxBrokerPending
 
@@ -94,12 +95,9 @@ func (m *muxBroker) Dial(id uint32) (net.Conn, error) {
 	return stream, nil
 }
 
-// NextId returns a unique ID to use next. There is no need for seeding the
-// rand package as the returned ID's aren't stored or used anywhere outside
-// the current runtime. So it's perfectly fine to get the same pseudo-random
-// numbers each time terraform is running.
+// NextId returns a unique ID to use next.
 func (m *muxBroker) NextId() uint32 {
-	return rand.Uint32()
+	return atomic.AddUint32(&m.nextId, 1)
 }
 
 // Run starts the brokering and should be executed in a goroutine, since it