release-22.1: multitenant: exclude background job reads/writes from tenant cost con…

[andy-kimball]

Backport 1/1 commits from #83005.

/cc @cockroachdb/release

---

Previously, reads and writes issued to the Storage layer by the job system
and by background jobs were included in tenant accounting. This is not ideal,
since we make a best effort to exclude operations from costing if they are
not under user control. This commit excludes the activities of the job system
from cost control, as well as the following jobs:

• Long-running migration job
• SQL stats compaction
• Span config reconciler

None of these jobs are triggered by user actions and none can be disabled by
users.

NOTE: A cost control exemption does not exclude CPU or Egress costs from
accounting, since those cannot be attributed to individual jobs.

Release justification: This minimizes Serverless RU costs for background operations as part of a Product push to make RUs more understandable for the Serverless GA release. This cannot wait until the next DB release. It is only used in multi-tenant code paths.
Release note: None

[blathers-crl]

Thanks for opening a backport.

Please check the backport criteria before merging:

• Patches should only be created for serious issues or test-only changes.
• Patches should not break backwards-compatibility.
• Patches should change as little code as possible.
• Patches should not change on-disk formats or node communication protocols.
• Patches should not add new functionality.
• Patches must not add, edit, or otherwise modify cluster versions; or add version gates.

If some of the basic criteria cannot be satisfied, ensure that the exceptional criteria are satisfied within.

• There is a high priority need for the functionality that cannot wait until the next release and is difficult to address in another way.
• The new functionality is additive-only and only runs for clusters which have specifically “opted in” to it (e.g. by a cluster setting).
• New code is protected by a conditional check that is trivial to verify and ensures that it only runs for opt-in clusters.
• The PM and TL on the team that owns the changed code have signed off that the change obeys the above rules.

Add a brief release justification to the body of your PR to justify this backport.

Some other things to consider:

• What did we do to ensure that a user that doesn’t know & care about this backport, has no idea that it happened?
• Will this work in a cluster of mixed patch versions? Did we test that?
• If a user upgrades a patch version, uses this feature, and then downgrades, what happens?

[cockroach-teamcity]

This change is 

[andy-kimball]

One last RU-related backport to 22.1. This is needed in order to minimize RU costs for background operations that are not under user control, like span config reconciliation or stats compaction. This is part of a larger effort to make RUs more understandable and request-based that we want to roll out soon. It should have no effect on non-tenant clusters.