HDDS-10327. S3G does not work in a single-node deployment

[Tejaskriya]

What changes were proposed in this pull request?

In a single-node deployment, no files could be written to Ozone via the S3G as it attempts to use a replication factor of 3 by default. The result of trying to write a file was as below:

$ aws s3api put-object --bucket bb1 --key k01 --endpoint http://localhost:9878 --body ~/temp1  
An error occurred (500) when calling the PutObject operation (reached max retries: 4): Internal Server Error

This was due to the way replication factor was being resolved on the client side. When ozone.replication config isn't set, storageType was defaulting to "STANDARD" which was leading to a replication factor of 3.
In this PR, a check is added to return null instead, leaving the resolving of replication factor to the server. This method is what is being followed when a key is written through ozone sh key put, as can be seen in OzoneClientUtils#validateAndGetClientReplicationConfig()

What is the link to the Apache JIRA

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

How was this patch tested?

Tested manually in a docker cluster with single datanode with all bucket types:

bash-4.2$ ozone sh bucket create s3v/bucketl -l LEGACY
bash-4.2$ ozone sh bucket create s3v/bucketo -l OBJECT_STORE 
bash-4.2$ ozone sh bucket create s3v/bucketf -l FILE_SYSTEM_OPTIMIZED 

$ aws s3api put-object --bucket bucketl --key key1 --endpoint http://localhost:9878 --body ~/temp2  
{
    "ETag": "\"b1946ac92492d2347c6235b4d2611184\""
}

$ aws s3api put-object --bucket bucketo --key key1 --endpoint http://localhost:9878 --body ~/temp2   
{
    "ETag": "\"b1946ac92492d2347c6235b4d2611184\""
}

$ aws s3api put-object --bucket bucketf --key key1 --endpoint http://localhost:9878 --body ~/temp2  
{
    "ETag": "\"b1946ac92492d2347c6235b4d2611184\""
}

bash-4.2$ ozone sh key list s3v
[ {
  "volumeName" : "s3v",
  "bucketName" : "bucketf",
  "name" : "key1",
  "dataSize" : 6,
  "creationTime" : "2024-02-22T20:08:01.501Z",
  "modificationTime" : "2024-02-22T20:08:01.530Z",
  "replicationConfig" : {
    "replicationFactor" : "ONE",
    "requiredNodes" : 1,
    "replicationType" : "RATIS"
  },
  "metadata" : { },
  "file" : true
} ]
[ {
  "volumeName" : "s3v",
  "bucketName" : "bucketl",
  "name" : "key1",
  "dataSize" : 6,
  "creationTime" : "2024-02-22T20:07:45.755Z",
  "modificationTime" : "2024-02-22T20:07:46.487Z",
  "replicationConfig" : {
    "replicationFactor" : "ONE",
    "requiredNodes" : 1,
    "replicationType" : "RATIS"
  },
  "metadata" : { },
  "file" : true
} ]
[ {
  "volumeName" : "s3v",
  "bucketName" : "bucketo",
  "name" : "key1",
  "dataSize" : 6,
  "creationTime" : "2024-02-22T20:07:55.081Z",
  "modificationTime" : "2024-02-22T20:07:55.107Z",
  "replicationConfig" : {
    "replicationFactor" : "ONE",
    "requiredNodes" : 1,
    "replicationType" : "RATIS"
  },
  "metadata" : { },
  "file" : true
} ]

[adoroszlai]

Thanks @Tejaskriya for the patch. Please take a look at test failures.

[kerneltime]

Is it possible to add a robot test where S3G's config does not have a replication type set? It can be done as a separate PR.

[adoroszlai]

Thanks @Tejaskriya for the patch, @ashishkumar50, @kerneltime for the review.