Allow subscriber to access cursor admin-api

[rdhabalia]

Right now, all cursor specific admin-apis (eg: skip-all, reset-cursor) can be only accessed by pulsar-system-admin or tenant-admin. Therefore, subscribers always have to request one of the admin to perform this operation. and this mechanism is not scaling because few of the subscribers require to call cursor-admin api more frequently.
Solutions

1. Allow all subscribers (user who has Consume permission) to access cursor-admin api.
Pros:
Easy and no need to store additional metadata.
Cons:
Problem with this solution : there is a chance that one subscriber can mess up other subscriber's cursor state by mistake.

2. Store subscriber auth metadata
In this solution: Broker stores subscriber auth metadata under AuthPolicies
Map<String, List<String>> subscriber_auth; // map between sub-name to list of allowed user's app-id.
Cons:
a. Global/Configuration-ZK will have to store additional metadata
(which should be fine because it will not require to create any additional zk-node and actual data size will not be large. Also only pulsar-system admin will be allowed to add sub-auth policy so, pulsar admin can always control znode metadata size).

So, I am thinking to address this issue with 2nd approach by storing subscriber-metadata into global/configuration zk. Any thought?

[rdhabalia]

we also want to address subscription-ownership usecase where pulsar enforces subscription access (consume, ack, admin-api) by only subscription-owner. One of the solution to configure sub-permission at namespace level implemented at #2981
however, it still doesn't enforce unless admin explicitly grants sub-permission to set of principals at namespace level.

Alternate solution to store subscription's principal-role at topic level in the topic-stat (managed-cursor) and whichever principal connects first to this sub will be the owner the subscription. So, whenever any principal connects to broker to access cursor, broker authorize connected principal against the role stored into cursor's stat (managed-cursor).
Also whenever, a subscriber application wants to change the subscription-owner there will be two options:

1. create separate subscription for newly changed role and drop old subscription
2. provide admin-api to change authorized role at managed-cursor , broker updates it and disconnect the existing connected consumers.

Enforcing subscription-ownership authorization can be configured at namespace policies by adding flag : enableSubAuthorization. Broker stores "role-name" and performs "sub-authorization" only if flag is enabled for the namespace so, by default this feature will be disabled and can be enabled when user requires sub-authorization across different sub in the topic.
So, it will be super-set of #2981 and #899 so, we don't need #2981 with this feature.

@merlimat @massakam any thoughts?

[sijie]

@rdhabalia was this fixed by #2981 already?