[Bug] Multi-role authorization does not work properly on granting topic level permissions based on ordering of roles in token

### Search before asking

- [X] I searched in the [issues](https://github.com/apache/pulsar/issues) and found nothing similar.

### Read release policy

- [X] I understand that unsupported versions don't get bug fixes. I will attempt to reproduce the issue on a supported version of Pulsar client and Pulsar broker.

### Version

Running on a UBI 9 base image, java version: openjdk 17.0.10, pulsar version: 3.1.2, 3.2.0, and 3.2.1.

### Minimal reproduce step

1. Enable a broker with multi-role authorization/JWT authentication.
2. Create token with multiple roles. Mine has these 2:
```
"roles": [
"Group_Test-admin",
"Group_Test-user"
]
```
3. Set the second of those roles associated with the created token as an admin role of the tenant or namespace
```
bash-5.1$ bin/pulsar-admin tenants update public -r Group_Test-user
```
4. Create a topic. I did it under the public/default namespace, but it doesn't matter.
```
bash-5.1$ bin/pulsar-admin topics create public/default/issue
```
5. Use the multi-role token (with the second as the only role with permission to access the tenant/namespace) to confirm that it has access:

6. Attempt to permit access to a role on that topic. Will fail with `{"reason":"Don't have permission to administrate resources on this tenant"}` despite being able to successfully run other commands against that tenant/namespace:

7. Switch admin role of tenant to first role in JWT:
```
bash-5.1$ bin/pulsar-admin tenants update public -r Group_Test-admin
```
8. Re-run access granting command:

9. Verify the access granting succeeded when the first role of the JWT has access:

### What did you expect to see?

I expected that this operation should have succeeded when either of the roles in the JWT were permitted access to the tenant/namespace.

### What did you see instead?

To be able to successfully perform the topic role permission granting action, the permitted role MUST be the first in the claim.

### Anything else?

Like I said before, I have tried this on multiple supported versions and in many different clusters/use cases. I find that this issue is not only on the POST but also the GET and presumably the DELETE. I have spent quite a while trying to find any other endpoints that are afflicted by this same issue, but my testing has only yielded this one. Any help is appreciated.

### Are you willing to submit a PR?

- [ ] I'm willing to submit a PR!