gh-152951 - Fix double DECREF when newblock fails during deque.extend calls

[stestagg]

When deque.extend is called, items from the passed-in sequence are appended using deque_append_lock_held.
deque_append_lock_held steals the reference to item, and (if needed) allocates a new block to store the item.

If the netblock call fails, then deque_append_lock_held DECREFs the item and returns -1

BUT: if deque_extend_impl sees the -1 return from deque_append_lock_held, it also DECREF's item again, despite not owning it any more. This can cause negative refcounts and crashes.

This fix removes the output DECREF, as it's handled by the inner func already.

There's no tests for this, as triggering an allocation failure within newblock is a bit tricky to do reliably.

• Issue: Double DECREF from deque.extend() if block allocation fails in deque_append_lock_held #152951

[sobolevn]

In two other places where we call deque_append_lock_held we pass Py_NewRef(item), so the reference would be owned by the deque.

Here we don't do that, because tp_iternext returns new references.
So, we can remove the second decref.

[stestagg]

Thanks again @sobolevn!

[miss-islington-app]

Thanks @stestagg for the PR, and @sobolevn for merging it 🌮🎉.. I'm working now to backport this PR to: 3.13, 3.14, 3.15.
🐍🍒⛏🤖

[bedevere-app]

GH-152971 is a backport of this pull request to the 3.15 branch.

[bedevere-app]

GH-152972 is a backport of this pull request to the 3.14 branch.

[bedevere-app]

GH-152973 is a backport of this pull request to the 3.13 branch.