HDDS-15137. [STS] Ensure each S3 API has an associated S3 Action

[fmorg-git]

Please describe your PR in detail:

• In order to restrict STS tokens on a fine-grained basis by action, each S3 api needs to be associated with an S3 action. For example, both HeadObject and GetObject S3 apis are associated with "s3:GetObject" action. The actions will not have the s3: prefix when used internally in Ozone and Ranger.

Most apis have a 1-1 mapping with api and action like the HeadObject and GetObject apis mentioned previously. In order to avoid having to update multiple call sites, an S3GActionIamMapper is introduced to leverage the already existing api audit functionality and map api names to actions in a thread local (S3Authentication.getS3Action()). Then in OmMetadataReader.checkAcls(), the maybeAttachS3ActionFromThreadLocal function is used to read the thread local and set the s3Action in the RequestContext if it exists.

However, CopyObject and UploadPartCopy are special cases. There is no "s3:CopyObject" nor "s3:UploadPartCopy" action, but rather they both require "s3:GetObject" action on the source object and "s3:PutObject" action on the destination object. For these special cases, a helper method runWithS3ActionString is introduced in EndpointBase.java so the proper permissions can be checked on the source and on the destination by temporarily overriding the value in the thread local while the operation is invoked, then setting it back to the previous value when done.

Additionally, this ticket contains additional fixes found after testing with these new changes. For example, since we now have fine-grained actions, we no longer need to distinguish listing files permission vs download files permission with LIST acl vs READ acl. Both apis can use READ acl.

This PR depends on #10009

What is the link to the Apache JIRA

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

How was this patch tested?

unit tests, smoke tests