Protect against common errors when using Trap

[mafredri]

I noticed there are a couple scenarios where it's quite easy to make mistakes when using Trap.

First one, trap registered too late:

// ... initializing code

tickerTrap := mClock.Trap().TickerFunc("updaterLoop")
tickerTrap.MustWait(ctx).Release()
tickerTrap.Close()

In a racy implementation, this will essentially block until the context expires (or test times out). If the context expires, it might be helpful to output some debug data like:

• We saw a call to TickerFunc/updaterLoop earlier
• We never saw the updaterLoop tag (e.g. in case of typos)

The second one, forgetting to Release call:

tickerTrap := mClock.Trap().TickerFunc("updaterLoop")

// ... code

tickerTrap.MustWait(ctx) // Missing .Release().
tickerTrap.Close()

This will result in the test timing out. As I see it there are two options:

1. Calling Close will automatically release all calls
2. Calling Close without releasing the call will immediately fail the test

I ran into this and it was impossible to debug. I had to find references of other code where this was used correctly. Obviously refreshing my memory and reading the docs would've also helped, but when I'm in the weeds, I sometimes forget to do that. 😄

[ibetitsmike]

2. Calling Close without releasing the call will immediately fail the test sounds a bit more explicit and user-friendly than option 1.

[spikecurtis]

For registering too late, what do you think about having the *Mock default to logging events like function calls, traps?