tablets: alter keyspace - loosen rejection criteria

[ptrsmrn]

Currently ALTERing is not possible if there's any other global topology request ongoing, but we should reconsider this restriction per #16723 (comment):

It's simpler to first restrict the conflicts by scope (keyspace) rather than by type.
Then, we can consider higher grain resolution by type within the keyspace.
Right now it would be acceptable to fail rf change if there's any other admin operation on the keyspace, like another rf-change, or even repair. As for tablet migration, we should serialize them with rf changes, but alter ks shouldn't fail if there are migrations going on in the background, but rather it should serialize with them.
It is questionable whether rf change should fail if there is a potentially long running node operation ongoing, like decommission or remove node. If we can detect them I think it would be better to fail rf changes until they're done.