HDDS-15618. Fix ListObjects to include single whitespace-only S3 object keys

[Gargi-jais11]

What changes were proposed in this pull request?

s3-tests test_bucket_create_special_key_names fails because a key named **' '** is created but not returned by ListObjects. OmMetadataManagerImpl.getOzoneKey() uses StringUtils.isNotBlank(), which treats whitespace-only keys as absent, so the object is stored under /volume/bucket instead of /volume/bucket/.
List object uses prefix /volume/bucket/, so the key is omitted. Fix key encoding to allow whitespace-only names

Expected: [' ', '"', '$', '%', '&', "'", '<', '>', '_', '_ ', '_ _', '__']
Actual:   ['"', '$', '%', '&', "'", '<', '>', '_', '_ ', '_ _'] 

  # missing leading ' '

At index 0: ' ' != '"' 

What is the link to the Apache JIRA

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

How was this patch tested?

Added unit test.

[priyeshkaratha]

Thanks @Gargi-jais11 for the patch. Changes LGTM

[ivandika3]

Thanks @Gargi-jais11 , left one comment.

[chungen0126]

Thanks @Gargi-jais11 for working on this.

As far as I know, HDFS doesn't support filenames with spaces. I'm concerning about how this change impact that. Have you looked into it?

[Gargi-jais11]

Thanks @Gargi-jais11 for working on this.

As far as I know, HDFS doesn't support filenames with spaces. I'm concerning about how this change impact that. Have you looked into it?

I have tested creating hdfs filenames with spaces and it does support. Evidence:

[datanode -1 ~]# echo "test" | hdfs dfs -put - "/tmp/ "

[datanode-1 ~]# hdfs dfs -ls "/tmp" | cat -A
Found 1 items$
-rw-r--r--   3 hdfs supergroup          5 2026-06-29 05:25 /tmp/ $

and even ozone supports creating key with space :

ozone sh key put /vol1/buck1/" " test
[datanode-1 ~]# ozone sh key list /vol1/buck1
[ {
  "volumeName" : "vol1",
  "bucketName" : "buck1",
  "name" : " ",
  "owner" : "om",
  "dataSize" : 11,
  "creationTime" : "2026-06-29T05:28:46.616Z",
  "modificationTime" : "2026-06-29T05:28:48.179Z",
  "replicationConfig" : {
    "replicationFactor" : "THREE",
    "requiredNodes" : 3,
    "minimumNodes" : 1,
    "replicationType" : "RATIS"
  },
  "metadata" : { },
  "tags" : { },
  "file" : true
} ]

The S3 issue was not “Ozone/HDFS rejects space keys.” It was a create vs list mismatch caused by a bug in how OM builds the internal metadata key. OM treated " " as “no key segment” and stored it at /vol1/buck1 instead of /vol1/buck1/.

[ivandika3]

Thanks @Gargi-jais11 for the update. LGTM +1.

[ivandika3]

Thanks @Gargi-jais11 for the patch and @chungen0126 for the review.