feat: Add T.Context()

[abhinav]

Background:
Go 1.24 adds a Context() method to testing.TB that returns
a context bound to the current test's lifetime.
The context becomes invalid before T.Cleanup functions are run.

Details:
This change adds a similar Context() method to rapid.T,
except this context is only valid for the duration of one iteration
of a rapid check.

For rapid.Custom, it's only valid for that call to the custom function.

Implementation notes:
The context is created lazily on the *rapid.T as requested,
using the testing.TB.Context as the base context if available.
A new unexported cleanup method on *rapid.T is called in strategic places
to cancel the context (if any) when its scope ends.

Future ideas:
The cleanup function added here can be expanded in the future
in support of a Cleanup method (#62).

[flyingmutant]

I think the implementation can be greatly simplified by both creating the context and deferring the cancel inside checkOnce. It would be both much simpler and obviously correct -- to the extent that I am not sure any tests would be necessary at all.

[abhinav]

That makes sense; I was hoping to use the cancel() machinery to also implement Cleanup later.
I think that might still work without leaking the internals into checkOnce if I do something like this:

func checkOnce(...) {
  // ...
  cleanup := t.prepare()
  defer cleanup()
  prop(t)
  // ...
}

Where prepare and cleanup assign and cancel t.ctx as needed.

Would that work/am I missing anything with it?

[flyingmutant]

Yes, I think something like that should work. Additionally, we can make context creation lazy, only after t.Context() was called. This way, we can avoid context creation overhead for the majority of cases where it is unnecessary (and t.prepare() would not be needed, only t.cleanup()).

[abhinav]

Changed as requested. This is much less disruptive, although defer t.cleanup was needed in three places to get desired behavior out of Custom generators and Example. I've kept the tests around as they verify this behavior.

To clarify, the behavior we get is:

• rapid.Check(prop): context requested inside the property is only valid for that iteration of prop.
• rapid.Custom(gen): context requested inside generator function is valid only for that call to gen. Outer property function that called rapid.Custom doesn't affect the lifetime of the context inside gen.
• Generator.Example(seed): context can only be requested for custom generators (I think), and same rule as rapid.Check(prop) applies

If this is not the desired behavior, we'll need to delete one or more of the t.cleanup calls.

[flyingmutant]

This is racy: after the unlock t.ctx may already be nil.

[abhinav]

🤦 derp. I had this right the first time around and decided to clean up some local variables for unknown reasons.

[abhinav]

Fix pushed

[flyingmutant]

Thanks, merged!