Describe the problem

The GC job waits out the GC TTL set on a tenant's RANGE DEFAULT zone configuration when GC-ing it. Now that we've introduced protected timestamps for secondary tenant ranges as well, we need to account for them when GC-ing tenants as well. This is very similar to how we take into account protected timestamp information when GC-ing tables/indexes on the system tenant today, where we wait till the protection is removed even if the TTL has expired.

It's an open question if we should be reading protected timestamp information that a tenant has set on its spans when deciding to GC the tenant or not. The tenant may have set a protected timestamp on its entire keyspace or on specific table's ranges. I'm inclined to say no, because whatever operation set the protection to begin with may not be around to remove it if the tenant is deleted. Think of a backup that was running when the tenant was deleted.

We should however take into account any protected timestamp the system tenant may have written over the tenant's keyspace when GC-ing a tenant. This includes a protected timestamp set explicitly over the tenant's keyspace or one that was set on the entire keyspace.

Jira issue: CRDB-13496