[SUPPORT] Retrospect the use case for GlobalDeleteKeyGenerator

**_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**
GlobalDeleteKeyGenerator is meant to be used for writes that have all Delete records and the index type is Global. However, We have added KeyGenerator to the table config validation path to ensure keygenerator cannot be changed. This begs the question how and why would one use the GlobalDeleteKeyGenerator if the keygenerator cannot be changed.

**To Reproduce**

Steps to reproduce the behavior:

1. Use a keygenerator other than GlobalDeleteKeyGenerator
2. Change to GlobalDeleteKeyGenerator in the next write.
3.
4.

**Expected behavior**

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

**Environment Description**

* Hudi version :

* Spark version :

* Hive version :

* Hadoop version :

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

* Running on Docker? (yes/no) :

**Additional context**

Add any other context about the problem here.

**Stacktrace**

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

Start by tracing GlobalDeleteKeyGenerator and the table-config validation path mentioned in the issue. Compare the all-Delete, Global-index write use case with the restriction on changing key generators. Done requires a maintainer-approved decision on whether the validation or the generator's supported use case should change, with the issue's behavior and tests aligned to that decision.

Written by the indexing model from the issue text.