These days people will just import the packages and the go tool will
do the right thing. We don't need to explain it.

Add a pointer to the git repo, though.

For golang/go#62645

Change-Id: I87fbf5d50e75120052f56ed6d4ac9977056cde9f
Reviewed-on: https://go-review.googlesource.com/c/time/+/624235
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Commit-Queue: Ian Lance Taylor <iant@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>

Change-Id: I603ca855eac736e90d2ba2bb7ce61981a4a91918
Reviewed-on: https://go-review.googlesource.com/c/time/+/638776
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>

Currently, there is a conversion from float64 to int64 when returning the duration needed to accumulate the required number of tokens.
When limiters are set with low limits, i.e. 1e-10, the duration needed is greater than math.MaxInt64.
As per the language specifications, in these scenarios the outcome is implementation determined.
This results in overflows on `amd64`, resulting in no wait, effectively jamming the limiter open.

Here we add a check for this scenario, returning InfDuration if the desired duration is greater than math.MaxInt64.

Fixes golang/go#71154

Change-Id: I775aab80fcc8563a59aa399844a64ef70b9eb76a
Reviewed-on: https://go-review.googlesource.com/c/time/+/641336
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>