gh-153297: Fix data race on assigning __name__ and __qualname__ to functions on FT builds

[sobolevn]

• Issue: Segfault with data race / double-decref in func_set_qualname under free-threading #153297

[sobolevn]

13

1 test failed:
    test_hashlib

failure is not related. Refs #153201

[kumaraditya303]

I think there are places where these are read without critical section so it doesn't fix all the cases.

[sobolevn]

Yes, like here :(

// Objects/genobject.c
assert(func->func_name != NULL);
gen->gi_name = Py_NewRef(func->func_name);

It now uses a critical section on func.
And the second fix is for function.__code__, which also now uses critical sections, when accessing __name__.

But, initialize_locals in ceval.c seem safe? I am not sure if I should touch it in any way.

[devdanzin]

This PR adds critical sections to __name__, __qualname__, and __code__ — but func_set_defaults / func_get_defaults (and func_set_kwdefaults / func_get_kwdefaults) have the identical Py_XSETREF-setter / Py_NewRef-getter pattern and don't appear to be covered. On a free-threaded build, racing f.__defaults__ read/write segfaults the same way (via a negative refcount in the debug build; func_set_defaults in release):

import sys, threading, time
assert not sys._is_gil_enabled()
class M: pass
def target(): pass
target.__defaults__ = (M(),)
stop = False
def churn():
    while not stop:
        target.__defaults__ = (M(),)
def read():
    while not stop:
        d = target.__defaults__; del d
ts  = [threading.Thread(target=churn) for _ in range(4)]
ts += [threading.Thread(target=read) for _ in range(8)]
for t in ts: t.start()
time.sleep(5); stop = True
for t in ts: t.join()

Debug FT: Python/brc.c:62 _Py_NegativeRefcount: object has negative ref count. Release FT: SIGSEGV in func_set_defaults (funcobject.c) ← PyObject_SetAttr. Worth extending this PR (or a follow-up) to __defaults__/__kwdefaults__ so the whole getsetlist is covered in one pass.

ETA: __annotations__ is also structurally unprotected and not touched by this PR (its getter goes through the lock-free lazy func_get_annotation_dict + func_annotate), but I did not manage to reproduce a crash via __annotations__ in 5 runs the way __defaults__/__kwdefaults__ do. The lazy-annotate path evidently has a narrower window. Flagging it as structurally-suspect but unconfirmed, in case it's worth covering defensively while touching this area.

Investigation and draft by Claude Code (Opus 4.8).