Fix getColumnMeta() for GH-15287 Pdo\Pgsql::setAttribute(PDO::ATTR_PREFETCH, 0)

[outtersg]

As stated in the UPGRADING, using the passthrough ("single-row") mode of libpq (introduced in #15287) forbids passing a new query while the current one's results have not been entirely consumed.
… But I didn't notice that ext/pdo_pgsql internally used new queries to fetch metadata (example use case: a call to getColumnMeta() while fetch()ing row by row will interleave the getColumnMeta()-triggered internal query to the database, with the results fetching for the user-called query).

This PR:

• prevents getColumnMeta() from interfering with an unbuffered user query
  by returning an empty value for every metadata that would emit an internal query, thus breaking libpq inner workings
• caches the table name so that 30 calls to getColumnMeta() won't call the database 30 times

This is a second take to #16249; compared to it:

• + The UAF is fixed
• + The egg-and-chicken problem at shutdown time may hopefully be fixed
  thanks to a rebasing on the latest master which includes fixes from ext/pdo_pgsql: Fix several lazy fetch defects #23065 (and maybe Introduce php_pdo_stmt_valid_db_obj_handle() #17567 too?)
• - I'm giving up on generalizing the PR to every internal query, focusing on getColumnMeta() only:
  This can be done on a call-by-call basis, as did in fact @KentarouTakeda for COPY in the aforementioned PR

Of course I'd feel more comfortable if there was a way to run the full CI chain before merging: any hint from GH rgulars?

[devnexen]

there are mix of fixes and cache improvements (thus should target different branches) but I ll have a better look this week end. Cheers !

[outtersg]

@devnexen wrote:

there are mix of fixes and cache improvements (thus should target different branches)
but I ll have a better look this week end. Cheers !

Thanks for the look!
Hoping that it will make reviewing easier this week-end, I reworded the commits, and resplit one of them.

Now we have:

1. 207de5c clearly is a new feature; in fact it will benefit all use cases, not limited to ATTR_PREFETCH 0
   → new feature PR to master?
2. d64c1f0 (extracted for the once big commit) is a small fix to test H->running_stmt->is_unbuffered instead of S->is_unbuffered.
   That's something I stumbled upon while making getColumnMeta() work, which it isn't related to, so it was better to give it its own commit.
   → new fix PR to 8.5? However I don't have a standalone test for it (it would theorically require running an unbuffered statement, not going all the way to the last result, then running a normal (ATTR_PREFETCH = 1) statement)
3. ac31dff was initially called "fix getColumnMeta() for ATTR_PREFETCH = 0".
   However as I always sold ATTR_PREFETCH = 0 as coming with unspecified behaviour regarding interferences between multiple running statements (including internal ones), in other words "Good enough to quickly dump the results of a query to a CSV file, everything else may crash the driver",
   I regard making ATTR_PREFETCH = 0 compatible with every other feature of Pdo\Pgsql to be best effort.
   → so new feature PR to master?
4. 9e25189 was initially a real fix (to a mis-nesting of an if into another one as seen in my original fix),
   but @KentarouTakeda fixed it in ext/pdo_pgsql: Fix several lazy fetch defects #23065, by fixing at the callers level;
   now my commit only factorizes back everything into the callee, so it is only a cleanup commit.
   → new cleanup PR to master? Or to 8.5? Or in the PR of 2.?

Tell me your preferred way of handling each part, so that I'll refactor the PR before you can comfortably review them.

[devnexen]

To summarize, the cleanup part (pt 4) and the cache (pt 1) -> master, the rest -> 8.5

[outtersg]

All 4 individual PRs created, as #23917, #23918, #23919, #23920.