Is your feature request related to a problem? Please describe.

Secondary tenants can set zone configs now (#67679). Before rolling it out, we ought to consider what fields should be settable by them, and/or what fields are considered by KV. The full set of settable parameters are:

There are a few reasons to tread carefully here (non-exhaustive):

• We currently cost tenants based on logical bytes. Given secondary tenant zone configs allow users to configure the replication factor, there's nothing preventing them from replicating data N-ways where N is the number of nodes in the host cluster. This could be expensive for the host cluster.
• Zone configs with our current costing make it possible for tenants to bus large amounts of data for free. By reconfiguring where the data is located (through constraints), it's possible to induce substantial egress.
• Setting low range_min_bytes could cause a large number of range split for the tenant. It's worth noting that this isn't limited by the mechanisms proposed in kvserver: limit the number of kv spans configurable by a tenant #70555.
• Setting super low or super high GC TTLs could cause KV to either scan for garbage frequently, or keep a lot more garbage data around (again, for free).

Describe the solution you'd like

If we're able to cost+rate limit things precisely, some of the aforementioned concerns go away. We could also start off with ignoring all fields down in KV and selectively accepting some of them as we gain confidence. That would however present as non-conformant ranges for secondary tenants, which could be bad-enough UX to instead disallow setting zone configs entirely.

Describe alternatives you've considered

See above.

Additional context

#67679 also powers MR abstractions for secondary tenants. Whatever we do has implications for MR usability/billing etc. We could also explore what it would mean allowing only MR set configs (though we lack the plumbing necessary today to distinguish between MR-set configs and user-set ones). Even for MR-set configs, some of the costing considerations above still apply.

+cc @ajstorm, @ajwerner, @nvanbenschoten, @arulajmani.

Jira issue: CRDB-13537

Epic CRDB-18604