backupccl: check privileges on types and schemas during backup

[pbardea]

This commit adds a check that ensures that the user running the backup
has USAGE privileges on the schemas and types they're backing up.

Note that this check doesn't actually enforce anything for now since
currently BACKUP must be run by an admin, which has to have ALL
privileges on both types and schemas. However, this check is consistent
with the other privilege checks we have for databases and tables.

Part of #53548.

Release note: None

[cockroach-teamcity]

This change is 

[solongordon]

Do we have the corresponding checks on the RESTORE side? For instance if a non-admin restores a table which makes use of a pre-existing enum, do we check that the user has USAGE privileges on that enum?

[pbardea]

I've been thinking about this more and since #53650 went in, I think that we need to be careful about allowing non-admins to RESTORE. The tricky part about allowing non-admins to restore is that RESTORE has always assumed that the users in the new cluster might not be the same users in the cluster that backed up the descriptors (even if they share the same name). Although they have the same name, they might not actually represent the same user (since a) BACKUP doesn't include the actual users that it restored and b) you might be restoring into an entirely different cluster).

This becomes an issue when allowing non-admins to RESTORE since we should now be checking if they have sufficient privileges on the descriptors they're restoring. However, to do this check we need to assume that the users on the restoring cluster are the same as the ones in the backing up cluster. Restore has long considered this assumption to be false.

I'm not sure what the best way forward here. I think to fully enable non-admins to RESTORE, we might need to support a more complete story around RESTORE handling users and grants, which might look something like #45359 + #45358. But these changes are a bit much to include during stability.

Also open to any suggestions if you have any ideas.

[solongordon]

I can understand the concern but I'm not convinced that "we should now be checking if they have sufficient privileges on the descriptors they're restoring." Since we enforce that non-admins need to use explicit credentials when restoring, doesn't that imply that they have privileged access to the backups? And in the case of restoring encrypted backups, the user would need to know the encryption_passphrase.

In my thinking, if a non-admin user has explicit permission to access the backups, there's no security issue in giving them permission to restore. After all, there's already nothing stopping such a user from creating a new cluster where they do have admin access and restoring the backup there.

[pbardea]

TFTRs!
bors r=solongordon,dt

[pbardea]

@solongordon, I think that makes sense - I think highlighting that in our docs would be useful, as we allow non-admin users to RESTORE. I can file a docs issues.

[craig]

Build succeeded:

• GitHub CI (Cockroach)