Currently, job scheduler exposes txn to job schedule implementation.
While the intent was to enable atomic schedule execution together with schedule record update,
exposing txn directly is dangerous. The implementation may use the transaction to perform wide reads, which then could result
in schedule txn being retried indefinitely, as show in #78465

In general, job scheduler should avoid locking records, should avoid using for update clause, and should not
expose low level primitives (txn) to job implementations. It should assume that job implementations are buggy, and must ensure
that an error in one of the job implementations does not destabilize the rest of the system (show jobs, show schedules, etc).

Jira issue: CRDB-14144