Add a per-job log_run option to disable job_run_details

[Christopher Pruijsen (cpruijsen)]

Summary

Adds cron.job.log_run (boolean, default true) so a single schedule can skip cron.job_run_details without turning cron.log_run off for the whole cluster. High-frequency jobs are the case in #366: at second granularity they fill the table and make it useless for the jobs you do care about.

• New cron.schedule(job_name, schedule, command, log_run) overload.
• cron.alter_job(..., log_run) so existing jobs can be changed without recreating them.
• Every run-detail insert and update now goes through one ShouldLogRunDetails() helper that requires both cron.log_run and the per-job flag, replacing the six open-coded if (CronLogRun) sites.

Existing jobs keep logging: the column defaults to true and the upgrade script backfills it that way.

Fixes #366.

On the shape

This is a boolean disable switch, matching the title of #366 and the cron.schedule(..., log boolean) signature originally asked for, and mirroring the existing boolean GUC. The argument is named log_run rather than log to match the GUC and the existing active column.

The thread later discussed an all / errors / off enum so failures stay recorded. I did not build that, because errors-only needs a policy this thread does not settle: a row is written when a job starts and updated as it progresses, so keeping only failures means either inserting and deleting on success, or deferring the insert until the outcome is known and giving up visibility of in-flight jobs. Those are different features. Happy to switch if you would rather have the enum, and the boolean is a compatible subset of it either way.

Upgrade note

Adding a parameter to cron.alter_job requires dropping and recreating it, so any GRANT or REVOKE targeting the old six-argument cron.alter_job(bigint,text,text,text,text,boolean) does not carry over. I confirmed this: across ALTER EXTENSION pg_cron UPDATE, information_schema.routine_privileges for a test grantee goes from one row to zero. The upgrade script comments it. Admins who granted execute to a role need to re-grant the seven-argument function.

cron.schedule_in_database deliberately does not gain the parameter, for the same drop-and-recreate reason. Schedule first, then alter_job.

Test plan

Run against PostgreSQL 17.11 with shared_preload_libraries = 'pg_cron'.

• make clean under the repo's -Wall -Wextra -Werror, no new warnings
• make installcheck passes, no regression.diffs
• CREATE EXTENSION pg_cron VERSION '1.0'; ALTER EXTENSION pg_cron UPDATE; reaches 1.7 with cron.job.log_run present
• cron.schedule('quiet', '1 seconds', 'select 1', log_run := false) writes no job_run_details rows over 12s, while a default job alongside it writes 11
• alter_job(..., log_run := true) resumes logging and log_run := false stops it, on a running launcher
• 3-arg cron.schedule on an existing named job updates the schedule and leaves log_run untouched
• cron.log_run = off suppresses every job including log_run = true

Regression coverage added to sql/pg_cron-test.sql is metadata-only, matching the existing suite, which never waits for the launcher. The launcher behaviour above was checked by hand.