tstime: add DefaultClock (#9691)

In almost every single use of Clock, there is a default behavior
we want to use when the interface is nil,
which is to use the the standard time package.

The Clock interface exists only for testing,
and so tests that care about mocking time
can adequately plumb the the Clock down the stack
and through various data structures.

However, the problem with Clock is that there are many
situations where we really don't care about mocking time
(e.g., measuring execution time for a log message),
where making sure that Clock is non-nil is not worth the burden.
In fact, in a recent refactoring, the biggest pain point was
dealing with nil-interface panics when calling tstime.Clock methods
where mocking time wasn't even needed for the relevant tests.
This required wasted time carefully reviewing the code to
make sure that tstime.Clock was always populated,
and even then we're not statically guaranteed to avoid a nil panic.

Ideally, what we want are default methods on Go interfaces,
but such a language construct does not exist.
However, we can emulate that behavior by declaring
a concrete type that embeds the interface.
If the underlying interface value is nil,
it provides some default behavior (i.e., use StdClock).

This provides us a nice balance of two goals:
* We can plumb tstime.DefaultClock in all relevant places
  for use with mocking time in the tests that care.
* For all other logic that don't care about,
  we never need to worry about whether tstime.DefaultClock
  is nil or not. This is especially relevant in production code
  where we don't want to panic.

Longer-term, we may want to perform a large-scale change
where we rename Clock to ClockInterface
and rename DefaultClock to just Clock.

Updates #cleanup

Signed-off-by: Joe Tsai <joetsai@digital-static.net>

tstime/tstime.go

@@ -60,6 +60,46 @@ func Sleep(ctx context.Context, d time.Duration) bool {
 	}
 }
 
+// DefaultClock is a wrapper around a Clock.
+// It uses StdClock by default if Clock is nil.
+type DefaultClock struct{ Clock }
+
+// TODO: We should make the methods of DefaultClock inlineable
+// so that we can optimize for the common case where c.Clock == nil.
+
+func (c DefaultClock) Now() time.Time {
+	if c.Clock == nil {
+		return time.Now()
+	}
+	return c.Clock.Now()
+}
+func (c DefaultClock) NewTimer(d time.Duration) (TimerController, <-chan time.Time) {
+	if c.Clock == nil {
+		t := time.NewTimer(d)
+		return t, t.C
+	}
+	return c.Clock.NewTimer(d)
+}
+func (c DefaultClock) NewTicker(d time.Duration) (TickerController, <-chan time.Time) {
+	if c.Clock == nil {
+		t := time.NewTicker(d)
+		return t, t.C
+	}
+	return c.Clock.NewTicker(d)
+}
+func (c DefaultClock) AfterFunc(d time.Duration, f func()) TimerController {
+	if c.Clock == nil {
+		return time.AfterFunc(d, f)
+	}
+	return c.Clock.AfterFunc(d, f)
+}
+func (c DefaultClock) Since(t time.Time) time.Duration {
+	if c.Clock == nil {
+		return time.Since(t)
+	}
+	return c.Clock.Since(t)
+}
+
 // Clock offers a subset of the functionality from the std/time package.
 // Normally, applications will use the StdClock implementation that calls the
 // appropriate std/time exported funcs. The advantage of using Clock is that