[RBAC] Updates to az ad app permission list/add/delete

[psignoret]

Description

Various updates to az ad app permission commands for managing required API permissions on app registrations:

• az ad app permission add
  • Remove message suggesting that running az ad app permission grant --id {id} --api {api} will grant the permissions added. (This was inaccurate and there's no command currently that can be used to grant both application and delegated permissions.)
  • Add support for identifying target API by identifier URI and service principal object ID.
• az ad app permission delete
  • Add support for removing an individual required permission.
  • Add support for identifying target API by identifier URI and service principal object ID.
• az ad app permission list
  • Set delegated permission grant expiry time to a date far in the future. This is slightly more accurate than the current approach, since the real "expiryTime" values are ignored by the service.
  • Add option to skip retrieving delegated permission grants (avoids several unnecessary queries and improves performance).
• Other:
  • Refactor show_service_principal to avoid an unnecessary query in several scenarios.
  • Expanded tests to cover more scenarios and to tear down more cleanly.

Testing Guide

See examples added in _help.py.

History Notes

[RBAC] az ad app permission list: Now includes a date far in the future as "expiryTime" when listing required permissions and there exists at least one tenant-wide delegated permission grant for the API in question. (The real "expiryTime" values are not enforced by the server, so it is more accurate to state the the permission grant expires far in the future.) Use az ad app permission list-grants to list all delegated permission grants.

[RBAC] az ad app permission add: Add support for identifying the API by identifier URI.

[RBAC] az ad app permission delete: Add support for identifying the API by identifier URI, and add support for removing individual required permissions.

---

This checklist is used to make sure that common guidelines for a pull request are followed.

• The PR title and description has followed the guideline in Submitting Pull Requests.

• I adhere to the Command Guidelines.

[yonzhan]

add to S169

[jiasli]

Hi @psignoret, thanks a lot for the contribution. We are on public holiday. I will review this PR tomorrow. By the way, az ad app permission grant does work with delegated permissions. Could you take a look at #12137 (comment)?

[psignoret]

Yes, az ad app permission grant does work for delegated permissions, but it only works for delegated permissions, not for application permissions, where az ad app permission add|delete|list apply for both delegated permissions ("Scope") and application permissions ("Role"). The message telling the user to call az ad app permission grant --id {id} --api {api} had two issues:

1. The message suggests that with az ad app permission grant any permission can be granted (when in fact it's only for delegated permissions).
2. If the user was to copy-paste the command proposed by that message (without any scopes specified), the scope value "user_impersonation" would be granted, which is not necessarily valid, nor is it necessarily the permission which the user had added to the required permissions.

I'm working on a separate PR to add support for application permissions (app role assignments). Once that's implemented, we can update admin-consent to use this.

[psignoret]

@jiasli Have you had a change to review this PR?

[jiasli]

Thanks @psignoret, I still haven't got a chance to review it as AD Graph API is not our priority. I don't think we will use the term admin-consent anymore. In fact, the whole command group needs an overhaul to better distinguish between delegated permissions and application permissions.

We actually plan to do this in MS Graph migration, as the current work may be discarded during the process.

[yonzhan]

add to S171