Currently, both the system tenant and secondary tenants use the same MaxTxnPriority level for high-priority transactions. This means that a system-tenant transaction running with high priority is not guaranteed to never block on a secondary-tenant transaction. This is a property that we would like to have for cluster-wide BACKUP, CDC, etc. in multi-tenant clusters.

To allow us to make the claim that a secondary-tenant transaction can never block (at least some subset of) system-tenant transactions, we should separate MaxTxnPriority into a system level and a tenant level. The system-level max priority should take precedence over the tenant-level max priority.

This is not quite as simple as defining a MaxTenantTxnPriority = MaxTxnPriority - 1 and calling it a day. That's because there are a few places where MaxTxnPriority is given special treatment, such as in the txnWaitQueue, in the lockTableWaiter, and in the evaluation logic for PushTxn requests.

SQL transactions running with "high priority" (BEGIN PRIORITY HIGH) should be given a different priority depending on whether they are part of the system tenant or not. The KV host cluster should reject all BatchRequests from secondary tenants with the system-tenant's max priority level.

Jira issue: CRDB-10844