builtins: mark some pg_.* builtins as strict

[mgartner]

Builtins defined using the UDF Body field will be wrapped in a CASE
expression if they are strict, i.e., CalledOnNullInput=false. When the
builtin is inlined, the CASE expression prevents decorrelation,
leaving a slow apply-join in the query plan. This caused a significant
regression of some ORM introspection queries.

Some of these builtins have filters that cause the SQL body to return no rows
if any of the arguments is NULL. In this case, the builtin will have the same
behavior whether or not it is defined as being strict. We can safely optimize
these builtins by setting CalledOnNullInput=true.

The following conditions are sufficient to prove that CalledOnNullInput can
be set for a builtin function with a SQL body:

1. The WHERE clause of the SQL query null-rejects every argument of the
   builtin. Operators like = and < null-reject their operands because
   they filter rows for which an operand is NULL.

2. The arguments are not used elsewhere in the query. This is not strictly
   necessary, but simplifies the proof because it ensures NULL arguments will
   not cause the builtin to error.

Examples of SQL statements that would allow CalledOnNullInput to be set:

SELECT * FROM tab WHERE $1=1 AND $2='two';

SELECT * FROM tab WHERE $1 > 0;

Fixes #96218
Fixes #95569

Epic: None

Release note: None

[blathers-crl]

It looks like your PR touches production code but doesn't add or edit any test code. Did you consider adding tests to your PR?

_{🦉 Hoot! I am a Blathers, a bot for CockroachDB. My owner is dev-inf.}

[cockroach-teamcity]

This change is 

[mgartner]

In a cockroach demo with ~1000 tables, the introspection query mentioned in #96218 takes ~225ms, must faster than the ~1.5s latency on v22.2.2.

One non-obvious side-effect of this change is that these builtins could potentially result in errors when presented with a NULL argument, whereas before they'd always result in NULL. In PG, these functions are listed as leakproof, so I don't think this should be a problem, but I want to spend a bit more time thinking about this before merging it.

[rafiss]

this lgtm! i think the same change should be made to the following, since they have the same pattern of using a single WHERE clause filtering by the first parameter:

• makePGGetViewDef
• makePGGetConstraintDef
• pg_get_functiondef
• pg_get_function_arguments
• pg_get_function_result
• pg_get_function_identity_arguments
• pg_get_indexdef
• col_description
• obj_description
• shobj_description
• _pg_index_position

[rafiss]

Will we be able to merge either this PR or #96545?

The performance regression is causing nightlies to fail (see #95569 (comment)), since the latency allows a different bug to manifest (#94337).

[DrewKimball]

I've added all the pg_.* builtins that I could prove would return the expected result when called with NULL arguments, and added corresponding tests.

[rharding6373]

Thanks for wrapping this up Drew!

Reviewable status: complete! 1 of 0 LGTMs obtained

[DrewKimball]

TFTRs!

bors r+

[craig]

Build succeeded:

• Bazel Essential CI (Cockroach)

[mgartner]

Thanks @DrewKimball!