sql: use SQL sequence as DescIDGenerator for non-system tenants

[nvanbenschoten]

Relates to #47904.

keys.DescIDGenerator is currently the only non-SQL key (i.e. no table ID prefix) that non-system tenants in a multi-tenant cluster will need in their keyspace.

This presents an interesting conundrum - if we want a per-tenant descriptor ID generator, where do we store it? Do we break down and encode a single non-SQL key under tenant ID-prefixed keys? This seems like a mistake.

Instead, we should explore pulling this DescIDGenerator into the SQL-domain properly, but exposing it as a sequence. As it turns out, sequences and the DescIDGenerator already have the exact same value encoding (they both use kv.IncrementValRetryable). If we had support for sequences at the time that the DescIDGenerator was added, we probably would have used them.

Proposal:

• create a new DescIDSequence with an ID of 7 for all non-system tenants.
• decide whether to use this key or the existing keys.DescIDGenerator when creating the key and when incrementing the key.
• optionally migrate keys.DescIDGenerator over.

Extended proposal:

• clear out and re-use ID 2, which has been vacated with the removal of the DeprecatedNamespaceTable. This is a bit more work, but has the elegant effect of placing the ID generator at the beginning of the ID space.
• optionally migrate keys.DescIDGenerator over. The timing of this is not pressing, so it could wait out any migration needed for the existing keys in the DeprecatedNamespaceTable.

Note that using ID 7 and placing this sequence in the SystemConfig span is not a concern, because this will range of keys will no longer be gossiped once #47150 is addressed.