Many check_pconnect behaviours are ineffective

Adapted from a Slack conversation, for public consumption:

we're actually getting a chance to diagnose check_pconnect https://github.com/php/pecl-database-ibm_db2/blob/master/ibm_db2.c#L2395-L2433 in the field and the lab, and we're getting some fun results. my lab environment has the following behaviour where:
=4 where it does a full exec works for determining if the persistent connection is alive
=3 where it just creates a statement handle does not
=2 where it gets a string attribute (DB type) does
=1 where it gets a bool attribute (autocommit) does not
and my methodology is "kill DB server job".
as for the behaviour diff, i wonder if this is possibly rooted in SQL/CLI server changes? these used to work. i.e. =3 has handles able to be created locally and remotely creating them is deferred, and =1 autocommit info is cached

(There is also a double-free I had mentioned, but this seems to be more in the PHP built-in web server. Eep!)

@kadler mentioned:

So CLI operates in the PHP job. Only if it needs to access SQL or call an SQL API to set something will it jump over to the QSQSRVR job.
It looks like SQLGetConnectAttr does do some SQ work before handling the SQL_ATTR_AUTOCOMMIT (which is an internal CLI attribute), but I'm not sure if that would bail if the QSQSRVR job is gone (edited)
SQLGetInfo does have a check after parameter validation if it knows the job is gone that it will give an error, but it doesn't check the status at that point, just the cached info.

The "throw things at a wall and see what sticks" nature of the current implementation was mentioned. I don't know if these originally worked, and the behaviours have changed, or if they always were the same and a variety of strategies were considered and implemented.

Later, he proposed SQL_CONNECTION_JOB_NAME and calling QUSRJOBI to fetch status of the job, instead of relying on SQL (which may have side effects). I worry if this would only really work for local instances though.

This is also pretty i-specific, but the LUW/z path is using the ping attribute anyways. It'd be nice if we had a CONNECTION_DEAD, but that would require a new version of i/TRs.

Start with check_pconnect in ibm_db2.c around lines 2395-2433 and reproduce the reported differences for values 1–4 after killing the database server job. Read the discussion of SQLGetConnectAttr, SQLGetInfo, SQL_CONNECTION_JOB_NAME, and QUSRJOBI. Done means establishing a reliable liveness check without depending on ineffective or side-effectful SQL behavior across the described paths.