ClusterID is used in various places to distinguish separate clusters, such as when joining gossip, making RPCs, or when interacting with persisted state, including in external locations such as backups. For example, if a BACKUP that is backing up "table 53" resumes and finds some partially written files at the destination location, it needs to verify that those files were written by the same cluster, and thus contain data for the same "table 53" that it will be reading from.

Currently, tenant SQL pods are initialized with the host cluster's ClusterID, meaning all tenants hosted on the same cluster believe they have the same cluster ID. This is unfortunate, as means that it fails to distinguish those tenants from each other; we would not want one tenant resuming another's backup, or joining another's DistSQL flow.

Fixing this isn't quite as simple as just changing the value to which ClusterID is set in the pod process, since when interacting with the host cluster, such as when making KV requests, the tenant should still be using that host's ID, so we'll want a separate ClusterID used at the SQL level, which can be initialized from the host cluster ID, but made unique using the tenant's ID (e.g. by adding it or hashing it into the host's ID). We don't want to just use the tenant's ID on its own though, both because it isn't globally unique, but even if were, it might not be at times, e.g. if a tenant is restored on a second cluster, thus we want something that is unique to that tenant on that host cluster, such a generating a new random ID each time a tenant is created or restored in a host cluster, or just by hashing the numeric tenant ID into the host cluster ID.

Jira issue: CRDB-12101