gh-143198: fix some crashes in sqlite3.executemany with concurrent mutations

[picnixz]

FTR, the reason why execute is actually not affected is that the iterator we are taking is built from a list we create ourselves so it's not possible to have "bad" side effects.

• Issue: Null pointer dereference in _sqlite cursor cache via re-entrant parameter iterator #143198

[picnixz]

There were more UAFs that I could find...

[picnixz]

@serhiy-storchaka So the split went well but... it's now a larger code =/ I also changed some variable names since we're talking about parameters everywhere but it's more arguments in this case or values. I can revert the change if you want (I'll make a commit for reverting and then we can decide whether to keep the revert or not) but I wanted to show you how it would be if the implementations are separate.

[picnixz]

I feel that there are a lot of tests that are really looking-alike. It's kinda annoying to have redundancy... and it won't get any better with the other PRs for sqlite where we I need to test the callbacks.

[serhiy-storchaka]

I also changed some variable names since we're talking about parameters everywhere but it's more arguments in this case or values.

I understand you, the term "parameter" is used here in different meaning from what we used to. But this makes the diff unnecessary large and makes harder to follow semantic changes. Can we leave this to a separate PR?

[picnixz]

Ok, I'll revert the naming changes and all other styling stuff. And then I'll address it separately.

[serhiy-storchaka]

There are still many pure cosmetic changes, but splitting execute/executemany was reverted (I do not know it the split would help readability). Could you please return to more early version?

If possible, I would prefer to add checks closer to the code that can be affected by closing the connection then to the code that can close the connection.

[picnixz]

Ok, let's avoid force-pushing more. I force pushed because I wanted a single commit for the follow-up PR

[picnixz]

If possible, I would prefer to add checks closer to the code that can be affected by closing the connection then to the code that can close the connection.

This is not always possible and it's more prone to errors in the future. The connection may be closed but we would check it way later. I tried to only add checks when the code in question never uses the sqlite3 API (e.g., pysqlite_microprotocols_adapt is purely using the Python C API so it doesn't matter that the connection is alive or not).

I can't make the diff smaller though. It's the minimal diff on the C code I can do.