gh-127124: Change context watcher callback to a callable object

[rhansen]

This enables developers to associate state with the callback without relying on globals.

Also, refactor the tests for improved readability and extensibility, and to cover the new state object.

This PR is an alternative to #127140.

This PR also incorporates #124741 because I don't think it makes sense to call a callable object without backing up the exception state first.

• Issue: Pass opaque state to PyContext_AddWatcher callback #127124

---

📚 Documentation preview 📚: https://cpython-previews--127247.org.readthedocs.build/

[rhansen]

Does this need a Py_VISIT somewhere? I didn't see any for the other fields in this struct, but maybe the GC does something special with this struct?

[rhansen]

I think my preference would be to create a new contextvars.ContextSwitchedEvent class that holds the Context object and pass that instead, but this is a smaller change.

[vstinner]

I think that I would prefer to add a void *data (or void *ctx) parameter to the callback API, rather than moving to PyObject *callback.

[ZeroIntensity]

I think that I would prefer to add a void *data (or void *ctx) parameter to the callback API, rather than moving to PyObject *callback.

I'm a tad concerned about void *data. See my comment here: #127124 (comment). That said, I'm not totally opposed to it, but we should definitely explore options before introducing this (and precedent for future void *) into the C API. Do you think this is worth bringing up on https://github.com/capi-workgroup/decisions?

[rhansen]

@vstinner So your preference would be PR #127140 (possibly with a void * instead of PyObject *) over this PR?

[vstinner]

@vstinner So your preference would be PR #127140 (possibly with a void * instead of PyObject *) over this PR?

I would prefer void* instead of PyObject*. But I never used this API and I didn't design it. So I'm not sure that I'm the right person to make a decision here.