HDDS-16110. [STS] Update key in sts revocation table

[fmorg-git]

Please describe your PR in detail:

• Previously, the key for the STS revocation table was the sessionToken. It was noted that sessionToken is not audited, so it's difficult to determine what it is from logs without turning on trace logs to log all headers. Therefore, the revocation key is being updated to a concatenation of the temporaryAccessKeyId (which already was being audited) and the originalAccessKeyId (which will be added to the audit log as part of the PR).
• As a side effect of testing this change (via TestAuditUtils), it was noticed certain inputs could cause the token parsing to fail that were not already covered, so this PR addresses that as well.
• The PR is divided into reviewable commits

What is the link to the Apache JIRA

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

How was this patch tested?

1. smoke tests and unit tests
2. manually checking keys in revocation table and then lowering the cleanup threshold to ensure they were still being cleaned up:

bash-5.1$ OZONE_OPTS= ozone debug ldb scan --db=/data/metadata/om.db --column-family=s3RevokedStsTokenTable --with-keys --limit=100
{ "ASIA2QG9LEIN3Z02YY8KB17S|svc-iceberg-rest-catalog/s3g@EXAMPLE.COM": 1786922690084
, "ASIABBSLHGE2UVFQAQWBTKT5|svc-iceberg-rest-catalog/s3g@EXAMPLE.COM": 1786922683068
, "ASIAJDZTUVSR7QXI72CXIWW1|svc-iceberg-rest-catalog/s3g@EXAMPLE.COM": 1786922693689
, "ASIAN92LMK2RK15CIUOUZJQL|svc-iceberg-rest-catalog/s3g@EXAMPLE.COM": 1786922686527
 }
bash-5.1$ OZONE_OPTS= ozone debug ldb scan --db=/data/metadata/om.db --column-family=s3RevokedStsTokenTable --with-keys --limit=100
{  }

3. manually checking S3g audit log to ensure originalAccessKeyId was added:

2026-08-16 23:30:41,877 | INFO  | S3GAudit | user=ASIAZJ3C5CP5QAQJ85V8C0MZ | ip=<redactedIp> | op=CREATE_BUCKET {"bucket":"[sts-bucket-aqievbhi]","originalAccessKeyId":"svc-iceberg-rest-catalog/s3g@EXAMPLE.COM","x-amz-request-id":"d756b407-431e-482b-baba-133946ee4757","x-amz-id-2":"5wC4dfBH"} | ret=SUCCESS | perf={} |  

[chihsuan]

Thanks for the patch! @fmorg-git I left a few comments. Otherwise, this looks good.

[chihsuan]

Since the value comes directly from the request, allowing | could create a revoke-key collision across users. Would it make sense to validate tempAccessKeyId against its generated format (ASIA plus 20 [0-9A-Z] characters) and bound both field lengths??

[fmorg-git]

good catch - updated

[chihsuan]

Including the full client-provided token here could make failed requests unusually noisy. Perhaps the token length, a short prefix, or a hash would provide enough debugging context without writing the entire value to the response and logs. What do you think?

[fmorg-git]

updated (sorry I forgot why I left it out originally)

[chihsuan]

nit: this uses the literal "originalAccessKeyId" while the OM side goes through OzoneConsts.S3_REVOKESTSTOKEN_ORIGINAL_ACCESS_KEY_ID. Could this share a constant so the two audit logs can't drift?

[fmorg-git]

updated