Add tests to log jobs using deprecated bootstrap, scenarios

[spiffxp]

Same pattern as CI policy changes... start with "should" tests that log jobs using deprecated things.

This can be used to build a help-wanted list, or shard out issues to specific job owners, etc.

/cc @amwat @MushuEE

[spiffxp]

FWIW, here's what I found running tests locally

jobs_test.go:1150: 403/2136 jobs do not use pod-utils
jobs_test.go:1192: 835/2136 jobs using deprecated scenarios

[spiffxp]

/test pull-test-infra-bazel
flake read tcp 10.60.209.54:51456->74.125.70.128:443: read: connection reset by peer

[spiffxp]

ref: #20760 for bootstrap migration

[MushuEE]

/lgtm

If I can find time I would love to build a struct for each job that can hold a little more metadata and help determine owners to see that Sigs have the most depreciated jobs.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: MushuEE, spiffxp

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• config/OWNERS [spiffxp]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[spiffxp]

If I can find time I would love to build a struct for each job that can hold a little more metadata and help determine owners to see that Sigs have the most depreciated jobs.

I was sortof headed in that direction in experiment/prowjob-report. There are a number of policy changes we want rolled out across all jobs, but we'd rather delegate that work out to the appropriate job owners. e.g.

• setting alert e-mails for all jobs
• setting pod resource limits for all jobs that run in k8s-infra
• jobs shouldn't use bootstrap
• jobs shouldn't use scenarios
• jobs shouldn't use kubetest

We have a bunch of distinct things that could imply ownership, I'm not sure how consistent they are:

• testgrid dashboard (but there can be many, I was guessing first sig- dashboard that wasn't sig-release)
• testgrid alert e-mail (but there are many non-sig e-mails)
• path for job / OWNER label for job (but this misses ownership of job results not produced by prow.kl8s.io that we ingest with kettle and testgrid)

ATM I wonder if it'd be best to try making path source of truth, and automatically added some labels at push-to-prow-time that could then end up in finished.json's metadata