Using Delete Partition operation with KEEP_LATEST_FILE_VERSIONS = 1 cleaner policy option evicts parquet files from S3 storage

**_Tips before filing an issue_**

- Have you gone through our [FAQs](https://hudi.apache.org/learn/faq/)?

- Join the mailing list to engage in conversations and get faster support at dev-subscribe@hudi.apache.org.

- If you have triaged this as a bug, then file an [issue](https://issues.apache.org/jira/projects/HUDI/issues) directly.

**Describe the problem you faced**
I'm having a Copy-On-Write (COW) table in AWS S3 bucket with some date based partitions. When I perform a `delete_partitions` operation on the Hudi table with cleaner policy configuration of `KEEP_LATEST_FILE_VERSIONS = 1`, hudi not only removes the partitions from the metadata (expected) but also actually deletes the partitions and the base parquet files from the S3 storage (unexpected).

I'm unable to understand why this is happening. As per Hudi's latest documentation, `KEEP_LATEST_FILE_VERSIONS` cleaner configurations deletes all but the latest file version from the storage. So when I perform the `delete_partitions` operation, are all the file groups in those partitions marked with a special `to_be_deleted` kind of version or the cleaning action first interacts with the table metadata, finds that the partitions and their files groups have been dropped and thus performs the actual cleaner action over those partitions. I'm more curious on why this is happening rather than how is this happening, as this is the favorable outcome in my use case.

NOTE: The actual file eviction from storage was not happening when the cleaner configuration was `KEEP_LATEST_COMMITS = 1`. In this is case, I had to perform an additional commit to trigger the cleaner action.

Write configurations used:
```

val FILE_VERSIONS_TO_RETAIN = 1

val options = Map[String, String](
DataSourceWriteOptions.OPERATION.key -> DataSourceWriteOptions.DELETE_PARTITION_OPERATION_OPT_VAL,
DataSourceWriteOptions.PARTITIONS_TO_DELETE.key -> listOfPartitions,
HoodieCleanConfig.CLEANER_POLICY.key -> HoodieCleaningPolicy.KEEP_LATEST_FILE_VERSIONS.name,
HoodieCleanConfig.CLEANER_FILE_VERSIONS_RETAINED.key -> FILE_VERSIONS_TO_RETAIN
)

// empty df is an empty dataframe

emptyDf.write
.format("hudi")
.options(cleanerOptions)
.mode("append")
.save(tablePath)
```

A clear and concise description of the problem.

**To Reproduce**

Steps to reproduce the behavior:

1. Create a Copy-On-Write (COW) hudi table in AWS S3.
2. Write some data into the table partitioned using `hoodie.datasource.write.partitionpath.field`
3. Drop some partitions using the write configurations provided above.

**Expected behavior**

A clear and concise description of what you expected to happen.

**Environment Description**

* Hudi version : hudi-spark3.3-bundle_2.12

* Spark version : 3.3.1

* Hive version : 3.1.3

* Hadoop version : 3.3.3

* Storage (HDFS/S3/GCS..) : S3

* Running on Docker? (yes/no) : no (AWS EMR 6.10.0)

**Additional context**

Add any other context about the problem here.

**Stacktrace**

```Add the stacktrace of the error.```

Start by reproducing delete_partitions on a Copy-On-Write table in S3 with KEEP_LATEST_FILE_VERSIONS set to 1, using the options and environment described in the issue. Compare the cleaner behavior with KEEP_LATEST_COMMITS and trace when partition metadata and parquet files are removed. Done means the observed behavior and its difference between policies are explained, with a regression test or documented correction if needed.

Written by the indexing model from the issue text.