HDDS-5101. Fix Maxkeys is invalid when delimiter is not null

[wzhallright]

JIRA: https://issues.apache.org/jira/browse/HDDS-5101?filter=-2

When get keys from s3g, the keys in my cluster is 
  main/chunk/00000000 main/chunk/00000001 ... main/chunk/99999999
if delimiter is not null, until all keys are queried, the count is always 1 ,so the max-keys is invalid.

[wzhallright]

The failed UT does not seem to be caused by my modification

[elek]

Thank you, @wzhallright to report this problem

Can you please give more information what is the original problem? What was your s3 request, and what was the expected result?

For me, the current behavior seems to be fine:

I tested it with creating keys in real AWS:

aws s3api list-objects --bucket=ozonetest3  | grep Key
            "Key": "copyobject/f1",
            "Key": "key1",
            "Key": "test/dir1/file1",
            "Key": "test/dir1/file2",
            "Key": "test/dir1/file3",
            "Key": "test/dir2/file4",
            "Key": "test/dir2/file5",
            "Key": "test/dir2/file6",
            "Key": "test/dir3/file7",

And executing aws cli:

aws s3api list-objects --bucket=ozonetest3 --prefix=test/ --delimiter=/ --max-keys=2 {
    "IsTruncated": true,
    "Marker": "",
    "NextMarker": "test/dir2/",
    "Name": "ozonetest3",
    "Prefix": "test/",
    "Delimiter": "/",
    "MaxKeys": 2,
    "CommonPrefixes": [
        {
            "Prefix": "test/dir1/"
        },
        {
            "Prefix": "test/dir2/"
        }
    ],
    "EncodingType": "url"
}

The result looks good to me. As the documentation says:

These rolled-up keys are not returned elsewhere in the response. Each rolled-up result counts as only one return against the MaxKeys value.

But this behavior is implemented with the existing code in Ozone.

What did I miss?