Add critical section to protect lim.limit

***Description***
Among 9 usages of lim.limit , 8 of them are protected by `lim.mu.Lock()`, but the one at line 226 is not protected. So I add a critical section to protect the read operation.

Among 8 usages of lim.limit that are protected, there are 2 usages at line 350 and 357 in function `lim.advance()`. They may seem to be unprotected at first glance, since `lim.mu.Lock()` doesn't appear in `lim.advance()`, but actually all three usages of `lim.advance()` are in critical section.

***How to trigger this bug***
I found this bug occasionally by my static checker, so I can only come up with a hypothesis to trigger it:

If one goroutine is calling `rate.WaitN()` and another goroutine is calling `rate.SetLimitAt()`, then the read operation in `rate.WaitN()` and the write operation in `rate.SetLimitAt()` will race.

***About my patch***
There are several ways to fix this bug, and I chose an efficient but not elegant one. Please let me know if you think other ways are better.

Change-Id: I229bc06a2caa483b9dfb0f4e682cfc144c5aa07c
GitHub-Last-Rev: 192792cf2c5d0d3e8d1ac1345ead38f6ab3c46bc
GitHub-Pull-Request: golang/time#7
Reviewed-on: https://go-review.googlesource.com/c/time/+/188898
Reviewed-by: Sameer Ajmani <sameer@golang.org>

rate/rate.go

@@ -223,7 +223,12 @@ func (lim *Limiter) Wait(ctx context.Context) (err error) {
 // canceled, or the expected wait time exceeds the Context's Deadline.
 // The burst limit is ignored if the rate limit is Inf.
 func (lim *Limiter) WaitN(ctx context.Context, n int) (err error) {
-	if n > lim.burst && lim.limit != Inf {
+	lim.mu.Lock()
+	burst := lim.burst
+	limit := lim.limit
+	lim.mu.Unlock()
+
+	if n > burst && limit != Inf {
 		return fmt.Errorf("rate: Wait(n=%d) exceeds limiter's burst %d", n, lim.burst)
 	}
 	// Check if ctx is already cancelled