Add support for contexts

[mafredri]

This might be a stretch for this library, but it would be cool if we had support for contexts, whether directly in this package or a sub-package like qzcontext.

Now, rather than doing context.WithTimeout you'd do clock.Context.WithTimeout(ctx, duration, "tag") (likewise for deadline) and be able to control expiry by advancing the clock.

[spikecurtis]

IIRC, the reason I have been gunshy is how to deal with contexts that already have deadlines based on a real clock being passed into the mock clock.

[mafredri]

Oh, that's an interesting thought. Off the top of my head

1. Discard timeouts not originating from quartz and print warning
2. Error, because the context timeout did not originate from quartz (limits usability, but maybe still useful within services)
3. Start watching the context that was passed into quartz context and track how long until it was cancelled -> measure against quartz elapsed time and if less, keep the quartz context active, otherwise cancel it.

For option 3, I imagine something like:

func quartzContext(clock *quartz.Clock, parentCtx context.Context) context.Context {
	detachedCtx, detachedCancelCause := context.WithCancelCause(context.WithoutCancel(parentCtx))

	startTime := time.Now()

	go func() {
		<-parentCtx.Done()
		duration := time.Since(startTime)
		parentErr := parentCtx.Err()

		// if clock advance > duration
		//   detachedCancelCause(parentErr)
		//
		// else track advancement and cancel eventually
	}()

	return detachedCtx
}

Edit: Oh yeah, forgot about ctx.Deadline() which could also be analyzed rather than the above timing. The context.WithoutCancel would still be useful.