Up until now, we've been pretty handwavy around the interaction between mutli-tenancy and zone configurations. Our proposed split of the SQL keyspace would leave each tenant with its own Zone table, so it would be natural for each tenant to have their own set of zone configurations.

However, for this to work properly, the consumer of the zone configs needs to be made aware of SQL tenants and the distributed storage of their individual zone configurations. A KV range will need to know which Zone table to search in when determining the zone configs that apply to it. There would likely be a large amount of disruption that would fall out of this. For instance, config.ZoneConfigHook (and all of its uses) would need to become tenant-aware.