KAFKA-19931 Inconsistency in handling the null config value, duplicate value, error code

[m1a2st]

This PR updates the behavior of Admin.incrementalAlterConfigs() to be consistent when invoked using bootstrap servers versus bootstrap controllers. The following changes apply specifically when using a bootstrap controller:

1. Null Config Values (DELETE Only) A null config value is allowed only when used with AlterConfigOp.OpType.DELETE. Supplying null with any other operation type will now result in an InvalidRequestException.

2. Duplicate Config Names Providing duplicate configuration names within the same resource will now fail with an InvalidRequestException.

3. Unknown Resource Types Requests containing unknown resource types will now fail with an InvalidRequestException.

These changes ensure the controller-based Admin API behaves consistently and predictably, aligning with broker-side validation rules.

FYI: https://github.com/apache/kafka/pull/20960

[chia7712]

@m1a2st I noticed another inconsistent behavior.

The following code fails on the broker but succeeds on the controller.

  admin.incrementalAlterConfigs(Map.of(
                    new ConfigResource(ConfigResource.Type.TOPIC, "chia"),
                    List.of(new AlterConfigOp(new ConfigEntry("cleanup.policy", "compact"), OpType.SET),
                            new AlterConfigOp(new ConfigEntry("cleanup.policy", "compact"), OpType.SET),
                            new AlterConfigOp(new ConfigEntry("flush.ms", "11000"), OpType.SET))
            )

[chia7712]

The following code fails on the broker but succeeds on the controller.

It appears this behaviour gets fixed also. @m1a2st would you mind updating the PR description and add the integration test ?

[m1a2st]

Thanks for @junrao comment, I have started a discussion thread.

FYI: https://lists.apache.org/thread/lqn0xw0zdfwl9m990otjvswzqh5bmy8v

[chia7712]

@m1a2st I noticed another inconsistency related to this patch. The controller does not validate the dynamic configurations when handling requests, which results in a misleading success response. By contrast, the broker checks the dynamic configurations immediately upon receiving the request, allowing users to catch invalid requests early. Would you mind fixing this as well?

[m1a2st]

I noticed another inconsistency related to this patch. The controller does not validate the dynamic configurations when handling requests, which results in a misleading success response. By contrast, the broker checks the dynamic configurations immediately upon receiving the request, allowing users to catch invalid requests early. Would you mind fixing this as well?

I also added this inconsistent behavior to the KIP, and I can align it as well.