KAFKA-20693: Fix NPE in AbstractHerder config-validation error handling

[wilmerdooley]

Description

AbstractHerder.maybeAddConfigErrors builds a human-readable error message by iterating over the ConfigInfos returned from config validation and appending the errors from each ConfigValue. The loop assumed every ConfigInfo it encounters has a non-null configValue(), but a ConfigInfo (or its inner configValue()) can be null, and dereferencing a null configValue() produced a NullPointerException in the error-handling path, so the REST layer surfaced a 500 with a confusing "Cannot invoke ... errors() because ... configValue() is null" message instead of the underlying validation error.

This change adds a null-guard inside the error-message-building loop in connect/runtime/src/main/java/org/apache/kafka/connect/runtime/AbstractHerder.java so that a null ConfigInfo or a ConfigInfo whose configValue() is null is skipped, and the existing validation error is returned to the caller as a BadRequestException.

Testing Strategy

Two unit tests were added to AbstractHerderTest:

• testMaybeAddConfigErrorsWithNullConfigInfoAndNullConfigValue exercises a ConfigInfos list that contains a ConfigValue whose configValue() is null as well as a null ConfigInfo entry, and asserts that maybeAddConfigErrors still completes by surfacing a BadRequestException (i.e. the validation error is reported rather than crashing the REST call with an NPE).
• testMaybeAddConfigErrorsWithNullConfigValueAndNoErrors exercises a ConfigInfos list whose ConfigValue has a null configValue() and no errors on the other values, and asserts that maybeAddConfigErrors returns false (no validation error to report).

Both tests use the existing testHerder(), addConfigKey, and addValue helpers and AbstractHerder.generateResult to construct ConfigInfos fixtures, so they directly cover the new null-guard branch without relying on any specific connector (e.g. Debezium) being on the classpath.

JIRA: https://issues.apache.org/jira/browse/KAFKA-20693