GeezerVison

…-142957)

The use of memmove and _Py_memory_repeat were not thread-safe in the
free threading build in some cases. In theory, memmove and
_Py_memory_repeat can copy byte-by-byte instead of pointer-by-pointer,
so concurrent readers could see uninitialized data or tearing.

Additionally, we should be using "release" (or stronger) ordering to be
compliant with the C11 memory model when copying objects within a list.

…132814) (GH-135689) (GH-144402) (GH-146033) (GH-142957) (GH-153791)

Combined backport of PRs from main branch, fixing free-threading data-races in itertools:

* gh-123471: make concurrent iteration over `itertools.cycle` safe under free-threading (gh-131212)
* gh-123471: Make itertools.product and itertools.combinations thread-safe (GH-132814)
* gh-123471: Make itertools.chain thread-safe (gh-135689)
* gh-123471: Make concurrent iteration over `itertools.permutations` and `itertools.combinations_with_replacement` thread-safe (gh-144402)
* gh-123471: make concurrent iteration over itertools.accumulate thread-safe (gh-144486)
* gh-123471: Make `itertools.zip_longest` safe in the FT build (gh-146033)

(cherry picked from commit 26a1cd4)
(cherry picked from commit 847d1c2)
(cherry picked from commit 0533c1f)
(cherry picked from commit 009c8c0)
(cherry picked from commit 3a24856)
(cherry picked from commit 9214e3f)

Co-authored-by: Pieter Eendebak <[email protected]>
Co-authored-by: Kumar Aditya <[email protected]>