We make concurrent iteration overitertools.combinations anditertools.product thread safe in the free-threading build.
The originalcombinations_next is renamed tocombinations_next_with_lock_held andcombinations_next is now callingcombinations_next_with_lock_held with a lock (similar foritertools.product)

We use a lock because it is easy to implement and avoids quite a bit of complexity (we have two pieces of mutable state to deal with:op->indices andop->result).

Issues that can occur without the locks:

• On initialization of the results structure theop->result can be overwritten, resulting in memory leaks

• The increment ofop->indices[i] athttps://github.com/python/cpython/blob/main/Modules/itertoolsmodule.c#L2379 is not safe. It can go out-of-bounds since the check is done earlier. This can lead to a segfault

• The refcount check for re-use of the result tuplehttps://github.com/python/cpython/blob/main/Modules/itertoolsmodule.c#L2346 is not valid in the FT build. Not sure whether this leads to crashes, but it will result in memory leaks.

• Updating the indices is not atomicitertoolsmodule.c#L2380-L2381. Non-atomic updates can lead to out-of-bounds issues.

The tests in this PR trigger some of these issues, although some are not visible (e.g. the memory leak), and it typically requires more iterations to result in a segfault. On my system > 2000 iterations gives a very high probability of triggering a segfault. The number of iterations is set much lower to keep the duration of the test < 0.1 second.

Performance with the locks is about 5% less for a single-thread (see the corresponding issue).

I refactored the tests to avoid duplicated code. Currentlycombinations andproduct are in the test, butcwr andpermutations have the same style and could be added as well (in a followup PR).

Could we do this without a full lock? It depends a bit on the iterator. Forproduct we could make the rollover check safe by changingindices[i] == PyTuple_GET_SIZE(pool) intoindices[i] >= PyTuple_GET_SIZE(pool) and use atomic operations in all operations dealing withop->indices orop->result. That would still leave memory leaks, but these are not crashes. And determining whether this actually safe (not crashing) requires some very careful reviews.

• Issue:Make concurrent iteration over pairwise, combinations, permutations, cwr, product, etc. from itertools safe under free-threading #123471