gh-142186: all-local PEP-669 events

[P403n1x87]

We make all the low-impact monitoring API events implemented by PEP-669 local on a per-code object basis. All the events can now be enabled on selected code objects. The distinction is now between instrumented and non-instrumented events, whereby the behaviour of the DISABLE sentinel value differs. For instrumented events, DISABLE will remove the instrumentation at the specific code location where the value was returned. For non-instrumented events, DISABLE will simply disable the event for the whole code object.

• Issue: Make the PY_UNWIND monitoring event local #142186

---

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

[P403n1x87]

@markshannon apologies for pinging you again, I appreciate you might be busy with other work. I would love for this to land in main before the first beta in May if possible 🙏

[markshannon]

Overall, this looks good in terms of semantics and capabilities.

I do have a problem with the naming, though. If we make all events "local", that does make the term "local" rather meaningless and terminology you use such as "instrumented local events" and "non-instrumented local events" is a bit opaque.
No user should really have to care about whether the implementation uses instrumentation or not.

Also, there is still a clear distinction between the events that can be precisely disabled and those that can only be disabled per code object.

So, with that in mind, I think we should still keep the terms "global" and "local" for the events they apply to now, and merely frame the change as "global events can now be turned on and disable on a per-code object basis".

In the docs, change "All local events can be disabled" to "All local events can be disabled per location"

It is unfortunate the functions get_local_events and set_local_events are so named as that does confuse the issue.

Sorry for taking so long to get back to this. It will get into 3.15

[P403n1x87]

@markshannon many thanks for your review.

No user should really have to care about whether the implementation uses instrumentation or not.

I totally agree with this sentiment, however a feature like the low-impact monitoring API sits quite close to the "stripped wires" that it becomes tricky to avoid that. However

there is still a clear distinction between the events that can be precisely disabled and those that can only be disabled per code object.

so as requested I have made some changes to the wording in the documentation and comments to try and capture this instead.