kvprober: use a test planning rate limit of zero

A nonzero limit has the potential to cause issues, albeit theoretical
ones, if the clock doesn't advance even 1ns between two operations.
This is mostly hypothetical and with zero we still have issues if the
clock jumps backwards, but still.

Release justification: non-production code changes
Release note: None

pkg/kv/kvprober/kvprober_integration_test.go

@@ -223,7 +223,7 @@ func initTestProber(
 	kvprober.NumStepsToPlanAtOnce.Override(&s.ClusterSettings().SV, 10)
 	// Want these tests to run as fast as possible; see planner_test.go for a
 	// unit test of the rate limiting.
-	p.SetPlanningRateLimit(time.Nanosecond)
+	p.SetPlanningRateLimit(0)
 
 	return s, sqlDB, p, func() {
 		s.Stopper().Stop(context.Background())

pkg/kv/kvprober/planner.go

@@ -130,7 +130,7 @@ func newMeta2Planner(db *kv.DB, settings *cluster.Settings) *meta2Planner {
 //   kv.prober.planner.n_probes_at_a_time cluster setting.
 //
 // CPU:
-// - Again scales with the the kv.prober.planner.n_probes_at_a_time cluster
+// - Again scales with the kv.prober.planner.n_probes_at_a_time cluster
 //   setting. Note the proto unmarshalling. We also shuffle a slice of size
 //   kv.prober.planner.n_probes_at_a_time. If the setting is set to a high
 //   number, we pay a higher CPU cost less often; if it's set to a low number,