gh-148442: eliminate race condition in list rich comparison

[KowalskiThomas]

What is this PR?

This PR is a fix for #148442, where the list's rich comparison function could return an incorrect result due a race condition in non-trivial __eq__ implementations of list elements.

It also updates test_equal_operator_modifying_operand which would previously assert two different lists were equal; it now properly asserts they are different.

• Issue: list's rich comparison has a race condition for non-trivial __eq__ and may return an incorrect result #148442

[serhiy-storchaka]

Could you please add a test specific to this issue, which shows why the new behavior can be better than the old one?

For example, let list1 = [x, 1] and list2 = [0, 0], where x > 0. During comparison list1 > list2, list1[0] is replaced with 0. Currently, the result will be False, even if both old and new values of list1 are larger than list2. Add also a test with replacing list2[0].

[KowalskiThomas]

@serhiy-storchaka I added two tests (and rebased on main since the branch was pretty out of date).

[serhiy-storchaka]

I afraid this is too heavyweight. No need to use threads if we can trigger the issue with a single thread.

[KowalskiThomas]

Ah yes, that's a very good point...

I just removed those tests and added two new ones that are single-threaded and do about the same thing with some... peculiar comparison operators.

Also, currently the release note says...

Fix a race condition in ``list.__lt__``, ``list.__le__``, ``list.__gt__``,
and ``list.__ge__``. Previously, under concurrent list mutation, the items
being compared could be replaced with other objects before the final comparison,
causing the final comparison result to be incorrect.

... should I also update it to frame it better and make it clear that it's not necessarily concurrent mutation? Even though that would be the most "usual" case I believe.