stats: include system.jobs in auto stats collection

[dt]

In #80887 we excluded system.jobs from automatic stats collection, but this is a system table that has 5 different indexes and is used by a wide variety of different queries coming from different places -- the jobs system itself, inspection tools, virtual tables, join with other jobs-info, etc, with a variety of different predicates. Choosing the best plan and index for each of these is obviously going to depend on the predicate and join and data distribution, but this is exactly the kind of information gathered statistics would provide the optimizer.

The lack of statistics here was recently implicated in an incident where a query on system.jobs that had two predicates -- one on jobs.job_type that it be one of x values and one on jobs.status that it be be one of y values; the plan chosen picked the job_type index instead of the job status index, even though there were 130,000 jobs of the matching type and only ~10 of the matching status.

Jira issue: CRDB-27344

[dt]

GH is claiming I removed those labels but I don't think I did? maybe some stale browser state or something. Putting them back.

[dt]

That said, I'm not sure this is a GA-blocker: all the queries we are running now are apparently running well enough, and we've manually index-hinted the one that wasn't, so I while I do suspect that in the long term we want stats on this table I don't feel strongly that we do in 23.1

[DrewKimball]

[yahor] We split off the most active/contentious part of the jobs table, so we may be able to reconsider collecting stats for the jobs table to ensure good index selection. One concern is that the auto-stats query that checks for existing auto-stats checks the jobs table.
[becca] We might start using views instead of virtual tables in the future, which might make statistics unnecessary. Worried about backporting a change to 23.1.0.

Removing the GA-blocker label. Plan is to enable stats on the jobs table for master, then consider back-porting to 23.1.1.