HDDS-14067. [STS] Plumbing and CLI utility to revoke STS token

[fmorg-git]

Please describe your PR in detail:

• Plumbing and CLI utility to revoke STS token. The CLI utility is invoked like in the following example:

ozone s3 revokeststoken -k ASIALMO9PNUEKTDPTWM4
Enter 'y' to confirm STS token revocation for accessKeyId 'ASIALMO9PNUEKTDPTWM4': y
STS token revoked for accessKeyId 'ASIALMO9PNUEKTDPTWM4'.

• This PR updates the CLI utility logic from the the previous PR HDDS-14067. [STS] Plumbing and CLI utility to revoke STS token #9435 so that it only requires one parameter instead of two, in accordance with the design.
• This PR depends on HDDS-14091. [STS] Deny access if STS token is found in revoked table #9445.

What is the link to the Apache JIRA

https://issues.apache.org/jira/browse/HDDS-14067

How was this patch tested?

unit tests (and prototype)

[ChenSammi]

Shall we allow the user who creates the temporal access ID and session tokens, to revoke the tokens?

[fmorg-git]

If we have the access key ID as the only input parameter to the CLI utility that revokes STS tokens, we wouldn't know who the user was that created the token. (The previous implementation that took both the access key ID and the session token as parameters to the CLI utility had the capability to allow the user who created the temporal access ID to revoke the token, but this was a change to the design that was not agreed upon in Slack discussions, so this PR modified that implementation). If we use the session token instead of access key ID as the one input to the CLI utility, then we would know who created the token, but this would again be a change to the design. Please let me know if you prefer the design to be changed in this way to allow the user who created the token to revoke the token.

[ChenSammi]

Please assign getUserInfo() to a local variable, so that we can avoid call getUserInfo() again in the following omRequest construction.

[fmorg-git]

updated